How to efficiently draw framebuffer content? How to efficiently draw framebuffer content? linux linux

How to efficiently draw framebuffer content?


For X11 use XShmCreateImage, write to XImage.data and make visible with XShmPutImage making sure to pass False for send_event parameter. You may also want to disable exposure events for the current GC; setting PointerMotionHintMask can also help.

SDL1 does most of the above but will use a shadow surface if there is a mismatch between user and display format and may perform unexpected color conversion. SDL2 tries to use hardware acceleration and may perform unexpected scaling and/or filtering. Make sure you're getting what you ask for to avoid hidden ops.

%50 cpu usage sounds like a lot for this blit at 30fps, I'd rewrite the sleep function as follows just in case.

do    errno = 0;while ( nanosleep(&ts, &ts) && errno == EINTR );


This may be an inherently expensive operation -- you need to move 240 MB/s from program (system) memory into the video card's (device) onboard frame buffer. Not only must that be physically copied, it must cross a device bus. Main memory copy speeds are up in the GB/sec, but device buses are relatively much slower.

Unless you're using a low-end video chip that uses the system memory for its frame buffer... ironically, that might be faster for this case.

Can you make the virtual display smaller?


I am not a graphic, Linux or optimization expert but I think this solution should work if the source is completely redrawn when updated.

Problem is you need to copy a frame buffer as soon as it is updated. Frame buffer is large (1920x1080x4 bytes) and you want to check every 1/30 seconds if it is updated.

I suggest writing a flag in the source buffer and to check every 1/30 seconds if the flag is still there. If it is not, then source changed and you need to recopy to destination and re set the flag.

As a flag you can use a single pixel (white pixel in a corner), or you can hide the flag in many pixels (like an hidden message in BMP). An other idea would be using the fourth byte of any pixel RGB value if the source is true color and the fourth byte is only used for memory alignment purpose.