10 Most Recently Updated Pages

GfxBench2D Gets an Icon

Hans de Ruiter — Thu, 12 Jan 2012 18:00:52 -0600

Both the AmigaOS and Windows versions of GfxBench2D have been updated to add an icon. This is something that I always wanted to add, but lacked the time (and I'm not a graphic artist). Anyway, thanks to Thomas Blatt - who created the icon - this is now a reality.

GfxBench2D for Windows 2.6

Hans de Ruiter — Mon, 10 Oct 2011 02:09:18 -0500

The Windows version of GfxBench2D has received another update. This version includes a workaround for an issue with buggy graphics drivers. On a small number of computers it would hang at the WritePixelArray test. This was due to a driver bug affecting the CopySubresource() function. It would allow the source-buffer to be locked for writing before copying of data from that buffer to the graphics card had completed, potentially enabling the old data to be overwritten before it had been used. Fortunately, there was a different method to wait until the operation was done, which waits for the GPU to be idle. This same method is used prior to each test to ensure the most accurate results.

The updated version can be found at the usual place.

Minor GfxBench2D Update

Hans de Ruiter — Mon, 19 Sep 2011 02:11:31 -0500

A minor update to GfxBench2D has been released for both AmigaOS (now at version 2.2) and Windows (now at version 2.5). This is a purely cosmetic update, and does not affect the benchmarking process in any way.

This update adds a user-agent string to the upload client, and adds the word "recommended" to the upload requester. The user-agent string is something that the upload client passes to the server to identify itself. Previously this was left blank. While this makes no difference operationally, it is something that should be filled in. The change to the upload requester's text is there to (hopefully) encourage people to upload their results. I have noticed a number of downloads that did not result in new results being posted. While uploading is 100% optional, the more people who upload, the more data there is for everyone to compare performance with.

GfxBench2D Download

Wed, 01 Jun 2011 19:23:46 -0500

GfxBench2D is a benchmark test tool that measures the 2D performance of graphics cards. Test results from various computers and graphics cards are available online.

Please download the version of GfxBench2D for your operating system:

AmigaOS 4.x - Download (view results)
Windows (XP or higher) - Download (view results)

Once downloaded, simply install the software and run it. There are only a few simple prompts to follow. Uploading results to the online database is optional, but recommended; the more results are uploaded the more useful the information is to everybody.

Thank you for trying out GfxBench2D.

NOTE: Ports of GfxBench2D for other operating systems are planned. If a version for your operating system is not available yet, please be patient. Since I cannot support all operating systems myself, I do plan on setting up a test server so that those willing to help with porting, can do so. However, this is not up and running yet. If you are interested to help out, then please contact me via email.

Source Code

I will be releasing the source-code at some point. However, I still have to decide in what form. If there is sufficient interest from others to help porting then I may set up a Google code project. Otherwise it will be provided as a downloadable archive here. If you are interested to help out, then please contact me via email.

Silverstripe EmogrifiedEmail Module

Sun, 11 Dec 2011 21:15:08 -0600

I have been using Silverstripe's newsletter module for years now, and it works well. It includes the ability to use templates, which is great. Use an HTML template, however, and complications arise. The problem is that Silverstripe is built around using HTML and CSS, whereas CSS support in email clients varies wildly.

Given the patchy CSS support, the safest solution is to embed the CSS style codes directly into the HTML tags themselves. Doing this manually is rather tedious. Fortunately, Pelago developed an emogrifier PHP class, and the Silverstripe newsletter-pagesource module, integrates it into Silverstripe. However, the newsletter-pagesource module only applies to newsletters generated from a website page, whereas I was looking for something more generic. Hence the EmogrifiedEmail module was created.

Overview

The EmogrifiedEmail class takes the HTML code being sent, and uses the emogrifier to embed CSS code contained in both external files and style tags directly into the HTML tags. It heavily borrows code from the Silverstripe newsletter-pagesource module, and a little on Mark Guinn's ProcessedEmail class. The following enhancements were added to the original (newsletter-pagesource) code:

Updated to the latest emogrifier code;
Turn relative URLs in the CSS code (e.g., background image URLs) to absolute URLs;
Deletes the unneeded CSS links and style tags from the HTML header; and
Fixed the final fallback option in the tidy() function so that it wouldn't add additional special characters to the HTML code.

NOTE: This was written on 13 December 2011. The newsletter-pagesource module may have been updated since then.

Installation

The source-code can be found on github at: https://github.com/hdrlab/Silverstripe-EmogrifiedEmail. It can be checked out using Git, or downloaded as a zip file. The module simply needs to be copied into your Silverstripe installation as per any other module and, after rebuilding (using http://yoursite/dev/build), it will be ready for use.

Due to the way that the Email class is designed, it was not possible to seamlessly integrate EmogrifiedEmail into the system without modifying other source-files. So, you will have to change any class that uses or extends the Email class, to use or extend EmogrifiedEmail instead. See how this is done with the newsletter module below. Also take note of a change to Silverstripe's HTTP class, which currently (as at 13 December 2011) is missing handling of list-style-image elements.

Integrating with the Newsletter Module

As said above, there was no 100% clean method of integrating EmogrifiedEmail into the system, so a few source-code adjustments are needed in order to get the newsletter module working with the EmogrifiedEmail module. There is only one essential change: open "code/email/NewsletterEmail.php", and replace the following line (line 8):

class NewsletterEmail extends Email {

with this:

class NewsletterEmail extends EmogrifiedEmail {

That's it; emails sent will now be emogrified. Those using Git can use this patch to make the change.

There is one problem though; if you preview a newsletter, the preview will use the original HTML code. If you wish to see the final email as it will be sent (ignoring the dynamic fields, of-course), then open up "code/NewsletterAdmin.php", and replace the following line (line 175):

return HTTP::absoluteURLs($email->getData()->renderWith($templateName));

with:

$email->setTemplate($templateName);
$email->debug();
return $email->Body();

This code is a bit of a hack, but $email->debug() triggers the emogrification process without sending an email. Once again, those using Git can apply this simple change using this patch.

HTTP Class Patch

This isn't actually needed but the HTTP class' absoluteURLs() (okay, urlRewriter()) function currently (as at 13 December 2011) doesn't handle list-style-image elements. This is described in bug ticket #6798, which includes the necessary patch.

It's a simple patch, which requires adding the following after line 64 in urlRewriter():

$regExps[] = '/(list-style-image:[^;]*url *\()([^)]+)(\))/ie';

Just in case the source-code has changed since writing this, line 64 looks like:

$regExps[] = '/(background:[^;]*url *\()([^)]+)(\))/ie';

Git users can patch their own code using this patch file.

Final Notes

Ideally this functionality would be integrated into Silverstipe's own Email class. In the meantime, this module works nicely. You may find that it doesn't convert all CSS code perfectly. This is a limitation of the emogrifier class. However, it shouldn't take much to adjust the CSS code to get what you want.

Fixing "Gave up waiting for root device" error in Debian

Mon, 12 Dec 2011 14:15:52 -0600

Yesterday I decided to do a full upgrade of my Debian server (apt-get dist-upgrade), and ended up regretting it. After it was finished, the machine would no longer boot. It would stop with the following message:

gave up waiting for root device. Common problems: boot args ( cat 
/proc/cmdline ) 
check rootdelay= (did the system wait long enough?) 
check root=(did the system wait for the right device? 
Missing modules (cat /proc/modules; ls /dev) 
ALERT! /dev/mapper/<<removed>> does not exist.
Dropping to a shell!

NOTE: <<removed>> was actually the name given to the root partition, which is not important.

I spent a very long evening scouring the internet for possible solutions, and found that none of them worked. The problem was caused by the upgrade switching to using initramfs for booting. Initramfs is a RAM filesystem that is supposed to contain everything needed to boot the system. Well, my Debian installation used logical volumes instead of plain partitions, and the necessary modules weren't included in initramfs.

Eventually I stumbled upon this page on a blog by Uwe Hermann, which described both the cause, and the solution. Basically, the lvm2 and cryptsetup packages were missing (or had been deleted).** To fix the problem, the following was done:

Booted from a Debian Live Rescue CD image;
Selected rescue mode from the rescue CD's boot menu;
Started a shell with the root set to /dev/mapper<<removed>> (it's in the menu, so there's nothing special to do);
Mounted the boot partition (/dev/sda1 in my case): "mount /dev/sda1 /boot"; and
Executed: "apt-get install lvm2 cryptsetup".

That's it. The installation of those two modules automatically triggers an initramfs rebuild. This rebuild requires that the boot partition be correctly mounted. If you forget to mount it first, then you can always mount it later, and execute "update-initramfs -u" manually.

FINAL NOTES:

I'm not sure if cryptsetup was actually needed, but it was too late for me to bother experimenting; and
There are a number of other reasons why you could get the same error message. So, the solution on this page is not guaranteed to work for everyone.

The RadeonHD_RM.resource

Hans de Ruiter — Mon, 24 Oct 2011 23:00:00 -0500

A while ago I mentioned the RadeonHD_RM.resource, and said that I'd give more details later. Several posts to this development log have come since, without a mention about this resource. Today, I'm going to deliver those details, and provide a glimpse of what is still to come.

The RadeonHD_RM.resource is a "render manager," hence the "RM" part of the name. It provides multiple separate drivers with access to the GPU and Video RAM (VRAM). This resource is part of the RadeonHD.chip 2D driver, and the 2D acceleration code for R600/700 chipsets (RadeonHD 2000-4000 series) has already been using it to send render commands to the GPU since the end of 2010. Since then, there have been bug-fixes, R600/R700 compositing has been implemented, and DVI output for Radeon HD 3000-4000. I have also been working on getting the RadeonHD_RM.resource ready for external drivers.

In addition to working on the driver, I also worked on a proof-of-concept test application (app). The test program allows me to test the RadeonHD_RM.resource in isolation of any 3D drivers. It has already helped me to find and eliminate several bugs, including an annoying vsync problem (fixed a few days ago).

I am pleased to announce that the RadeonHD_RM.resource has now progressed to the point where an external driver can render 3D graphics on a Radeon HD 2000-4000 card. Screenshots are at the bottom of this page, but this really is best seen in video form (hint, best viewed in HD at 720p):

You can also view the video on youtube.

NOTE: A big thank you to hostcove for helping to deliver a high quality video that was not made by pointing a camera at the screen.

Except for the Workbench screen, all of the graphics that you see in the video was rendered via the RadeonHD_RM.resource on a Radeon HD 4650. In fact, the test app doesn't even open the Picasso96API.library; it doesn't even know that Picasso96 exists. No, it's not a driver, but it demonstrates that the RadeonHD.chip driver is ready for 3D.

Features

Some of the features in the proof-of-concept are:

GPU based 3D transformation and lighting
Per-pixel lighting (8 lights, each rendered in its own render pass, and one controlled by the mouse)
Bump-mapping

All of these are things that MiniGL/Warp3D cannot do. The test-app may be primarily for testing the RadeonHD_RM.resource, but it also gives you a glimpse of what will be possible when OpenGL 2+ support is finally available on AmigaOS. These new capabilities are why I embarked on the RadeonHD driver project in the first place.

What's next

Obviously, getting the Gallium3D drivers working is next, but not by me personally. Hans-Joerg Frieden has been working on porting and integrating MESA into the OS, and will continue to do so. There is still much work for me to do on the RadeonHD.chip driver itself. There are bugs to fix, and RadeonHD_RM.resource may be ready for 3D, but it's not yet ready for release.

What's most important is that an external 3D driver is now possible. We're almost there.

How to Set up and Use Your Own (Linux-Based) Development Server in Minutes

Hans de Ruiter — Tue, 30 Dec 2008 22:57:36 -0600

A new section of this website is finally complete. It provides instructions on how to set up and use a Trac and SubVersioN (SVN) server. Trac and SVN are incredibly useful tools for software development. In my opinion, these tools are indispensable tools for any software project. Of course there are alternative products available, but these are the ones that I am familiar with, and they are free. Trac is a minimalist software project management too, providing methods of tracking bugs, enhancement requests and overall progress from start to finish. SVN is a source-code version control system that tracks changes made to the source-code.

One reason for not using these tools has always been the difficulty in setting them up. This is particularly true for newcomers to software development who are already overloaded with the volume of information that they must digest. In order to make this easier, procedures and scripts to automate the process of installation are available here. The scripts will help get a server up and running in minutes.

All of the instructions and scripts were designed for and tested on Debian Linux. They are tailored toward a personal or small business set up. All communications with the server are via secure connections, meaning that the server is suitable for use via the internet. It would be a fairly simple matter to change this setup for open-source projects. However, I would recommend using online services such as Sourceforge which are already set up to perform this task; this would relieve you of the task of server maintenance and backups.

I hope that this new section proves useful to others. If anything, the scripts will reduce the time required to set up and use these tools to a matter of minutes, instead of requiring hours of scouring the internet to discover what exactly how things should be done.

Month in Review - December 2008

Hans de Ruiter — Thu, 01 Jan 2009 02:10:15 -0600

This month has seen significant additions to this website, as can be seen with an increase from 112 to 132 pages. I have had much more time to spend on this site than usual, due in part to not having my Amiga one and, thus, being unable to work on the RadeonHD for Amiga OS 4 project. There as also been more free time in general.

The major addition to the website has been the a section on setting up and using a Trac and Subversion server. This section was written as I personally went through the process of setting up such a server and wrote scripts to automate the process. More additions to the website are planned as and when the underlying work is finished. Writing tutorials/instructions does slow down the overall development process, however, it should provide more complete documentation than if I try to write things down at a later date.

AWStats and Webalizer switched off mysteriously round 23 December, so the statistics from these tools are useless for this month. However, Google Analytics is so much more powerful in terms of web traffic analysis that this is no big loss.

The statistics for the last month:

Attribute	Value
Number of Pages	132
Size of site	36.7 MiB (+ 39.7 MiB for the database)
Number of Visits	1017 (Google Analytics)
Number of unique visitors	763 (Google Analytics)
Total page views	2375 (Google Analytics)
Bandwidth	822 MiB (server control panel)
Adsense Revenue	$1.33

One important thing to note is that Google Analytics only sees page-views on the public part of the site, whereas AWStats and Webalizer also log the accesses by me to the CMS pages that are used to maintain and update the sit.

A snap-shot of visitor locations on 1 January 2009.

Custom Print Dialog Toolkit

Thu, 13 Jan 2011 00:09:49 -0600

While wxWidgets provides an extensive amount of classes and widgets, one area where it did not meet my needs was printing. Sure, wxWidgets contains everything needed to print, but it is designed to use the Operating System's (OS') built-in print and page setup dialogs. These dialogs were inadequate for my needs. So, I set out to create a custom dialog. I quickly discovered that wxWidgets did not provide a means to get the information necessary to build such a dialog. Functionality for simple things such as getting a list of all printers, and the page sizes supported by a printer were not available. So, I decided to create a custom print module to address this short-coming. Rather than creating a new dialog class, this toolkit provides an API to obtain the necessary information and functionality for a developer to create their own dialog class. In my opinion, this provides the greatest flexibility.

Since I know that I am not the only one who wanted to build custom print dialogs, I am releasing the code here under the licensing terms as wxWidgets. Ideally, this module would become an official part of the wxWidgets package. and then extended However, that decision is for the wxWidgets team to make.

Features

Provides an API to get a list of printers and identify the OS' default printer
Provides an API to get a list of supported page sizes
Provides an API to get the non-printable margins
Enables custom print dialogs to use the native printer preferences dialog
Integrates with the existing wxWidgets print system

Current Status

At present this toolkit only supports Windows. It implements the features (listed above) that I personally needed for my own work. A demo application is included which shows how to use the basic features of the toolkit.

If anyone adds support for additional operating systems, wishes to extend this toolkit with additional features, or has suggestions for improvements, please contact me. I will be more than happy to merge quality improvements into the downloadable source-code archive.

Download

wxPrintCustom.zip