2D acceleration: is it still needed?

Haiku graphics driver API (accelerant) have 2D acceleration API (B_FILL_RECTANGLE, B_INVERT_RECTANGLE, B_SCREEN_TO_SCREEN_BLIT). app_server has code to use that, but it is disabled for long time. It was discussion that it is actually slower that current software drawing. Also if I understand correctly, it doesn’t support back buffer and will cause terrible flickering if enabled especially after disabling flickering workarounds (#15623, hand-made double buffering per-application).

Is it still needed or it can be dropped now? Can accelerated 2D drawing be used on back buffer and copy regions between buffers? If not, it is not useful anymore. Only hardware cursor and overlays may be still useful.

I think that acceleration should be focused on OpenGL based 3D acceleration because modern video card work in that way and it is more flexible (can operate on multiple buffers, alpha-blend and scaled blitting, shader-based gradients etc.).


If it does not cause a lot of inconvenience in support, I think you can leave it. On many machines of the past decade, simply moving windows and even the cursor gives a CPU load of 5-15%.
Even if the implementation is not too quicker than the software one, if it allows you to free up processor resources, why not? (The opinion of not a programmer but an ordinary user)

It can’t. It is disabled for a long time and enabling cause terrible flickering because 2D acceleration don’t support double buffering.

If I remember correctly, it is 2D acceleration that allows embedding of video windows for example.
So, would it be possible to separate parts that can be useful and others and if yes, only keep and activate those parts?

Otherwise, as the code is disabled, does it cause problems staying there?
Maybe it has been kept around for people who want to work on graphic cards drivers, as an example, allowing them to better understand how to communicate with the hardware?

The accelerated code has several parts:

  • Overlays for videos, available in some drivers, we should keep it
  • Hardware cursor, available in some drivers, we should keep it
  • Accelerated drawing operations (asking the graphics card to draw lines, fill rectangles, etc)

This last part is not so useful in the current architecture for several reasons:

  • Modern graphics card do not support anything like that. They do 3D acceleration, but not 2D
  • Our drawing is done in software for the most part because we want antialiasing, etc. So the accelerated drawing wouldn’t be used all that often
  • Currently the framebuffer is stored in main memory, and copied to the videocard when ready to display, I think? On modern video cards we could put two buffers in videoram, but there is no acceleration available anyway. On old video cards where there is acceleration, there isn’t enough space in video ram for two framebuffers. BeOS did use a single framebuffer and draws directly to it, which creates some other problems (flickering because the drawing cannot be perfectly synced with the screen refresh)

The idea for Haiku is that we would go to the BeOS single-buffer mode (possibly with acceleration) on low memory systems. The 8MB needed for a 1080p framebuffer may not seem a lot today, but back when this was all designed, event the 3MB of a 1024x768 one could be up to 10% of your available RAM… How things have changed :slight_smile:

In the modern world, even 2D acceleration would probably use something like OpenVG (the 2D variation of OpenGL) and plug itself at a higher level in app_server (maybe similar to the remote_app_server).

So, yes, the old 2D acceleration code does not seem all that useful now…


In the interest of a cleaner code base, I’d be in favor of removing it. While old systems may benefit from it, any developer who would work on re-enabling this code would have to have access to the hardware to test it on. This seems unlikely. Is there even a single Haiku graphics driver which implements this accelerant API? Also, I would expect that the performance is also worse on older systems, because the way screen updates work is no longer optimized for these code-paths.


Drivers made by Rudolf were accelerated. I’m not sure for recent cards but at least old AGP cards Nvidia and Matrox should have the code.

If 2D acceleration will be removed at some point, then there should be an announcement about it. It cannot just be buried in release notes, as users who rely on 2D accel. may miss it.

It is disabled already. So, nobody relies on it unless they are compiling Haiku themselves and activating it.

1 Like

In that case, a short announcement will do.

Even then, it probably does not work. The code has been disabled for 10 years or more. I don’t expect it to even compile.