This fact along with the need for a fast rendering method meant writing a display engine from scratch, something I luckily have a lot of experience with! The Simple DirectMedia Layer (SDL) library takes care of setting up the display mode and checking for keystrokes, etc. The graphics library will not interact with work being done by the GPU's because it is designed to rely 100% on the CPU.
#BOINC SCREENSAVER PROBLEM CODE#
60% of the code is the blitting engine and graphics library, another 30% is code for graphics display look-up tables. The programming overhead for 3d rendering is about 20 lines of code in 1,119 total lines. The difficult part is quickly representing the sheer magnitude of the data (100,000 stars), which is handled by the custom 7-bit graphics engine (the 8th bit is used to perform 4 pixel sums simultaneously instead of 1 at a time). Since look-up tables are used, the overhead is there, but it is manageably small. I realized I did not mention the 3d to 2d conversion overhead. Here are the comparisons of the 5 test runs: The human eye can see at about 60-70 fps so we have the following options in the interest of speed:Ī) render at various angles without motion during transitions (stationary rendering takes close to 0% of the CPU)ī) only move every 30 seconds or so and use ~25% of the CPU only during these brief transitions, 0% the rest of the time (stationary)ĭ) darken most of the stars, showing only the nearest ones while moving, all stars while relatively stationary over the wedgeĮ) remove most of the stars, showing perhaps 10,000 instead of 100,000 If you have one of these, then odds are it is already being used to integrate for the Milky Way Project so providing such support might be counter-productive. Unfortunately, I think it would require a programmable graphics card to provide on-board accelerated support for pixel-summing. It might be significantly faster on machines with hardware-accelerated blitting. Transparency takes time similar to pixel summing on my machine. The problem with 1x1 stars is that they do not allow boundary blending, so even if the images look good in a still-frame, they look noticeably choppy when moving slowly across pixel boundaries no matter what the frame-rate is. These values are based on 100% CPU usage, so multiply the frame-rate by the desired CPU percent to get the expected frame-rate. The rest is memory copying and operations with very little cost. Now that everything is in look-up tables, rendering only takes a handful of multiplications and divisions per star even at 16x16 px. I do not expect things to get much faster. The application is far enough along now to give an answer to this. Transparent-blit stars 8x8px (faster when graphics-card accelerated, otherwise slower than pixel-summing):Įdited to add : what's the performance loss from A-Z?" Sharp pixel-summed blur circles 4x4px ( 38 fps ): Pixel-summed blur circles 8x8px ( 26 fps ): Transparent draws flatten the image, much like pixel-rendering, so the default setting is pixel-summed blur circles:
I welcome any comments on the different modes. Here are some screenshots of a frame from a simple test demo. It doesn't get any faster than single-pixel rendering, but some people prefer effects over speed. For those that need more speed, I am building in options to manipulate the blur-circle radius, average luminosity and cut-off distance, screen resolution, and a single-pixel rendering mode.
Luckily, the screensaver does not have to show all 100,000 stars at once, so by limiting the view distance for the majority of the time, the screensaver should be able to maintain its frame-rate. For now, we are planning to cap the screensaver CPU-time at around 10 or 15%. Beyond that, optimization would require assembly-code which I am avoiding, because this application currently compiles on any platform and I hope to keep it simple, but fast. From a few tests, it looks like it might double that frame-rate (fingers-crossed). I am currently optimizing the floating-point routines to use fixed point math and trig-function look-up tables. For those of you that don't know, this laptop is not made for graphics. For 8x8px-accurate blur circles I get 26 FPS rendering 100,000 stars on my Dell Inspiron 1501, AMD 64 Athlon X2, using a mainboard video card w/shared memory. The screensaver is almost fully optimized.
0 kommentar(er)
