Recently, I implemented in FreshLib images that can be scrolled without actually moving data, by only changing the origin of the image inside the pixel array. This trick accelerates the scrollable GUI elements significantly.

The structure of the OS independent image is:



As you can see, it has a wrapW/wrapH size that is smaller or equal to the allocated size of the image. This way, the image can change its size without reallocating memory.

The orgX/orgY fields define the physical point of the [0, 0] pixel. By moving it, the whole image scrolls vertically (orgY) or horizontally (orgX).

The output of such images to the screen is a little bit tricky - by decomposition of the image in 1..4 rectangles and drawing them in the proper order on the screen surface.

The whole source is in the repository, in NoCanvasGUI branch.

In the attachment is a test application that demonstrates the above features. The source is in the project "freshlib/test_code0/TestGraphics.fpr" in the mentioned branch. The archive contains only the binaries for Windows/WINE and Linux.

Notice, that with the default window size, the demo application is expected to make very high FPS values (2000..3000fps). Maximize the window in order to get more reasonable values and to enjoy the beautiful background.

Comments, fixes or simply FPS reports are welcome.
Enjoy.

Neat. FPS was about 340 at fullscreen (1280x800) before opening Win's Snipping tool for a screengrab. Is this GDI, GDI+, neither, on Windows?

Also, after selecting the app icon in the taskbar to minimize it, the app stalls. I reproduced it ~4 times (Windows).

I got GDI working in FASM about a month ago for the first time, was tricky trying to figure out DIBs, bitmap formats, without any prior familiarity with it. I had Petzold's book but unfortunately sold it long ago, didn't think I would need it past the first few chapters.

Just noticed you posted a source link, will take a look later...!

Win7 x64 I was able to get steady ~480fps
min: 62fps
max: 656fps
(I moved and resized the window a lot)

130fps fullscreen 1920x1080

@Enko - What hardware is this. It looks strange, because the 130fps on 1920x1080 is a good value, but 480 or even 656 is pretty low for small window sizes.

@donn - thanks for the bug report. I will fix it. In Windows, the drawing on the windows surface is by BitBlt function (file: freshlib/graphics/Win32/images.asm, procedure DrawImageRect).
In Linux, the drawing is a little bit more complex. When available SHM extension of X server, the drawing is by using XShmPutImage. When the SHM extension is not available XPutImage is used. (file: freshlib/graphics/Linux/images.asm procedure DrawImageRect).

Well, I fixed the bug with the hanging in Windows. It was because the real Windows sets the window size to 0,0 on minimizing, while WINE does not.

Also, the slow FPS rate with small windows on original Windows is because of the pretty slow text rendering in Windows. It is FreshLib flaw, because the need for transparent text rendering, that Windows API can't provide. This way FreshLib uses some dirty tricks that slow down the text output.

In Linux it uses directly FreeType library and the text output is much, much faster. I am wondering isn't it better to switch to FreeType in Windows as well, but I am not sure this library is available on most Windows systems.

Serious implications with the purpose of that code Johnny!

Screen magnifier, masking with clip --all type of sh!t. I'm salivating thinking about the possibilities. Many prominent imaging editing & creation systems use a similar technique for non-destructive masks and the like; very professional target John (pan & zoom too, oh yeah).

Noice stuff --will be checking it out.


Might be a bit premature, but the lil frame thingy you're developing specifically for GUI has potential to allow display of all types of stuff like image previews, document regions like when developing HTML; etc. Might be an awesome generic container if you haven't already considered it --supports your libs' re-usability focus (something like a dc [generic object]).

I also like the fact that those whom tested the code are using frame counters --that honestly rocks!

Keep up the good work you guys & gals (as applicable)!
I just noticed it's threaded --wow...

fixed, but not updated in the upload 200fps in 1080p, cool. i think it is very good also for any content scroll to use this kind of algorithm.

what about video/text/vectorial/3D etc... application?

Well, sorry for not updating the executables. But you can always compile from the sources.

This image structure is the base image format in FreshLib. Its purpose is exactly for fast and cheap content scrolling in the GUI elements. The above is simply test demo for testing the code for bugs and performance evaluation.