Diskeeper 2016 is definitely Better Than Version 2011 was.

Both mentioned versions of Diskeeper have approximately the same features, including to perform ‘Fragmentation-Prevention’, by caching files that are being written to the HD for longer than Windows would normally do so, in order to be able to write contiguous output blocks, and including ‘Background-Defragmentation’, for which we can schedule times of day or days of the week we want it to happen.

One fact I find odd under Windows, is that no effort is made where the user can see it, to distinguish between ‘Fragmentation’, and ‘FS Corruption’, the latter of which can also be called ‘File System Inconsistencies’. The idea in the minds of Windows software developers seems to be, that whatever we have, we have, that being, whatever is linked.

But a deeper fact which I know about Windows, is that if an efficient defragmenter is let loose on the File System, and it encounters actual FS Corruption, it will cause Windows systems to crash – to do one of those nasty reboots which the user did not tell them to do. This has led to some people not being able to get through a defrag, before the computer would crash, until those users ran a File-System Check, between reboots, using ‘Checkdisk’, which solved their problem for them.

When either version of Diskeeper is told to do a manual defragmentation, it does not go as deep, as one of its scheduled, Background Defragmentations go. This was a major reason for My Previous Posting.

What I have learned, is that the 2016 version of Diskeeper, does a much more thorough job of cleaning up the File System, even during the Background Defragmentation, which its software company no longer touts as a major feature. The software company mainly touts the Fragmentation Elimination feature. But BG-defrag having taken place successfully last night, and having produced the report it did, makes me confident again, that it was able to find FS Corruption which neither its 2011 version, nor Windows Checkdisk, were able to recognize. And so I may be able to keep the present O/S installation on ‘Mithral’.

diskeeper_1

In fact, having been able to perform heavy computation continuously from 13h00 yesterday, until 4h00 this morning, while Diskeeper 2016 was installed, and then allowing this software to do a BG-defrag, also impressed me about the idea, that at least the H/W seems to be quite stable.

Dirk

(Edit : ) It would not be obvious how “Fragmentation-Prevention”, would reclaim those 13,184 blocks. But according to the System Software I studied, there is an answer. There exists Internal Fragmentation, and External Fragmentation.

Continue reading Diskeeper 2016 is definitely Better Than Version 2011 was.

OGRE 1.10 Compiled On Laptop ‘Klystron’

One of the projects which I had been working on, while my Hewlett-Packard laptop was running Windows 8.1 and named ‘Maverick’, was to compile “OGRE 1.10″ on it to the best of my ability. And one mistake which I was adhering to, was to insist on using the ‘MinGW’ compiler suite. OGRE developers had already tried to convince me to use the MS compiler, since that was a Windows computer, but I did not comply. This was particularly pedantic of me, since by now a free version of Visual Studio is available, that can compile OGRE.

So now that the H/W has Linux installed on it, I recommenced compiling OGRE, with native compilers and tools. But the results were not exactly spectacular.

One reason for the lackluster results is, the fact that ‘Klystron’ currently has ‘Mesa’ drivers loaded for its Radeon graphics card, instead of having the proprietary, binary ‘fglrx’ driver. Mesa will give it OpenGL 3.3 tops, while ‘fglrx’ would have given it OpenGL 4.5. And the latest OGRE samples include samples with Geometry Shaders, other OpenGL 3 features, and even some Tessellators, which would be OpenGL 4 features.

Apparently, when one pushes any Mesa Drivers to their limits, these will bug out and even cause the X-server to freeze. Thus, when I switched from testing the OGRE OpenGL 2 rendering engine, to its OpenGL 3+ rendering engine, I ran in to an X-server freeze.

This did not force me to hard boot, because often, during an X-server lockup, I can <Ctrl>+<Alt>+F1 to a console window, from there do a user and a root login, and then issue an ‘init 6‘ command, which will usually do a controlled reboot, in which all file systems are unmounted correctly before the restart.

There is one detail to what the Mesa Driver does, which I like a whole lot.They allow for shader code written in the language Cg to run, even though Cg is a legacy toolkit developed by nVidia, for use on nVidia graphics cards and not on Radeon.

The fact that the Mesa Drivers allow me to do that, differently from the limitations which were only imposed on me under Windows 8.1, means that with OGRE 1.10, the Terrain System finally works 100%. OGRE 1.10 uses GPU-generated terrain, whereas most graphics engines rely entirely on their CPU, to create terrain. The earlier inability to get terrain to work with this system, was more crippling than anything else.

But as long as I am not using the ‘fglrx’ drivers, all attempts to get OpenGL 3 features to work with OGRE utterly fail, including any hope of ISO surfaces, which rely on Geometry Shaders, and any hope of GS-based particles. My particles will be limited to Point Sprites then.

What one does in a situation such as this, is not just to throw out OGRE 1.10, but rather, to disable modules. And so I disabled the GL3+ rendering engine, as well as one ‘HLMS Sample’, and am now able to get many of the samples to run, including, importantly, the Terrain Samples.

 


 

Also, there remains an advantage to using Mesa Drivers, which was pointed out to me already on the Kanotix site. The Mesa Drivers allow hardware-acceleration of high-bandwidth, 2D video streams, via ‘vdpau’, while if I was to use ‘fglrx’, the decoding of MP4 Videos would be limited to CPU decoding, which is in itself lame, if we ever wanted to watch serious video streams. And since that laptop has a screen resolution of 1600×900, wanting to watch videos on it eventually, remains a very realistic prospect.

Dirk

 

(Edit : ) I suppose that one question which I should be asking myself, about why perhaps, the OGRE 1.10 GL3+ Rendering Engine does not work, would be whether this could be due to some incompatibility with the GL3.1 Desktop Compositing which I am already running on the same machine. There have been past cases, where OpenGL 2 from an application did not agree with OpenGL 2 Desktop Compositing, but those cases have generally been solved by the developers of the desktop managers.

On ‘Klystron’, I have rich desktop effects running, that use GL 3.1. So it does not seem obvious, that the Mesa Drivers as such, have problems implementing GL 3.

Also, there is a follow-up thought, as to why maybe, Cg was not working before. Whether or not our graphics cards support Cg, it is a necessary component of OGRE, to build their Cg Program Manager. Under Windows 8.1, I was always unsure of how to provide the OGRE Dependencies when building OGRE. But among those dependencies I always linked in a file named ‘Cg.dll‘, the origin of which was unknown to me.

It is exactly the sort of goofy mistake I would make, perhaps to have taken this DLL File from the install folders of Cg on ‘Maverick’, but for some reason simply to have taken a 64-bit DLL, into my 32-bit OGRE build, or to have taken a DLL from somewhere, which may not have been compatible for some other reason.

At least when we install dependencies under Linux from the package manager, such issues as linkage of code and location of folders, are also taken care of by the package manager. So I am sure that the Cg Program Manager belonging to OGRE, recognized the nVidia Cg packages when compiling now. It is just a bit odd that those were native Cg libraries with header files, while my graphics drivers remain the Mesa Drivers.

 

An Alternative to OpenShot under Linux

In the past, I used to be a fan of the non-linear video editor named “OpenShot”. It is the kind of editor which allows for multiple source clips to be added to multiple, parallel timelines, and for transitions and effects to be added, to put those together into a longer video presentation. One could say that OpenShot was a software-end to the process of compositing. In the past, I had even custom-compiled version 1.1 of OpenShot on the Linux computer I name ‘Walnut’, and gotten that into a state in which it could be used. This means that I did not write the source code in any way, but that I did overlook a lengthy process, by which this source code could be translated into an executable program, on a platform which would not ordinarily have supported it. However, v1.1 still lacked many of the features which later versions claim to have, and that eventually become necessary. V1.1 did not have the Blue-Screen or Green-Screen, Chroma-Key effect.

These days, OpenShot v1.4.3 is directly available through the (Linux) package manager under Debian / Jessie. But I don’t use it, mainly because I cannot. I seem to have discovered that there are major stability issues with recent versions of this video editor. On my Linux box named ‘Phoenix’, this video editor actually caused my desktop to freeze – not once but three times. Almost all my other, package-installed software, is comparatively well-behaved, and I have no other reason to think, that my graphics chipset is in any way faulty.

Under Linux, even a defective application run in user space, should not be able to get the desktop to freeze.

There is also a Windows version, v2.0.6, which I next tried to install on the Windows 7 computer named ‘Mithral’. I did not like the fact to begin with, that this is the type of install which asks the user to reboot Windows for the changes to take effect. But then I also found that the Windows version would constantly crash. Next, having OpenShot v2.0.6 installed under Windows, actually prevented a ‘GPG4Win’ application named “Kleopatra” from working on ‘Mithral’. This last detail worries me.

Yet, after I uninstalled OpenShot from the Windows computer and rebooted again, Kleopatra was working again.

And so the bottom line for me is, that this once-great video editor is now too unstable to be used.

On the Debian / Jessie, Linux computer named ‘Phoenix’, I can use “Kdenlive” instead, which does more or less what OpenShot was supposed to do, and which does these things without crashing. Kdenlive also offers the user to place video clips he supplies into multiple timelines, and to apply transitions and effects, and does include the “Blue Screen” (alpha / translucency) effect.

But under Windows, I can still only see paid-for solutions to this need.

Dirk

 

Printing Legal-Sized on a Canon MX922

Currently my printer is a “Canon MX922″, and perhaps it would be a good subject for a later posting, how I installed the CUPS device drivers to use it under Linux. Being a WiFi-printer, it is also shared by my two Windows machines.

In keeping with modern times, my bank only sends me certain forms in electronic form, that used to be mailed to us in their entirety, on paper. And some of the forms, which I need to submit along with my Tax Declarations each year, are in Legal-Sized format, which in Canada and the USA means 8.5 x 14 inch paper, instead of a 8.5 x 11 inch format.

I had never realized that this printer is capable of receiving paper in the 8.5 x 14 format, until today. Basically, my Linux and Windows software have two different behaviors, when told to print an 8.5 x 14 PDF on 8.5 x 11 paper, but both of those behaviors is wrong. Under Linux, “Okular” tends to resize the document to fit, while the Windows software tends to write past the end of the sheet. A resized document will not get scanned correctly by the Revenue Agency’s machines.

On the MX922 printer, there are two paper trays. The upper tray is for smaller formats of paper, as well as having interesting features that seem to allow printing directly onto Blu-Ray discs.

The lower tray accepts the 8.5 x 11 sheets. But if we take out the supply of 8.5 x 11 (Letter-sized) sheets, we see that underneath there is a slight feature in the plastic of the tray, which seems to lock into one of two openings. Between the two openings there is labeling stamped into the plastic, which has the letters “LGL” and which seems to point between the two openings.

What one needs to do, is to depress the button which seems to fit, with our thumb, not to pull on that part of the tray, but to pull on the outermost edge of the tray, so that the button we’re holding down slips out from under the visible surface of the tray, and then slides into the second opening, which is located in the tray facing down, further away from the body of the printer, next to the first opening. Once the button clicks into this second opening, the tray is able to accept 8.5 x 14 sheets.

One needs to be careful though, not to apply brute force if something doesn’t move, because this mechanism looks fragile, and could easily be damaged if force was used.

Also, one needs to remember that after we have extended the tray and fed in Legal-sized paper, we still need to slide the tray back into the printer, so that the printer will register the fact that paper is available. At which point in time extra length of tray will be standing out from the printer, where the tray was flush when accepting 8.5 x 11 paper.

Next, our software needs to be told that it is printing to 8.5 x 14 sheets, so that this software does not decide to resize, or otherwise to mismanage the print job.

Once the correct paper-size is set up on the printer, my Linux “Okular” program is as able to print the tax documents, as the Windows “Acrobat Reader DC” is.

Dirk