History log of /haiku/src/servers/app/drawing/MallocBuffer.h
Revision Date Author Comments
# 77870621 20-Oct-2021 Augustin Cavalier <waddlesplash@gmail.com>

app_server: Drop gfxcpy and implement some TODOs about checking for graphics memory.

We still do not know if the accelerant buffers are graphics memory or not,
but in my testing (on the VESA driver), the only time I could get _CopyRect
to be called was where the buffer was in fact not graphics memory.
So that should provide a performance improvement there.

On the other end of things, this should resolve unaligned video memory
access problems on RISCV, and potentially other platforms, as gfxcpy32
did not attempt to align pointers; it should also improve performance
as memcpy will usually be faster than our custom gfxcpy here.

Most of this code has not been touched since 2006 or so.

Change-Id: I40b0345c5d47f2b45acafb14f03fd3a24d2042a8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4315
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>


# 8940f93c 01-Apr-2005 Stephan Aßmus <superstippi@gmx.de>

AccelerantHWInterface now uses a MallocBuffer as RenderingBuffer for the back buffer instead of a BitmapBuffer, which under Haiku does not work.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12217 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 8940f93c1d5bce994b062b866fe230c5fa8517e1 01-Apr-2005 Stephan Aßmus <superstippi@gmx.de>

AccelerantHWInterface now uses a MallocBuffer as RenderingBuffer for the back buffer instead of a BitmapBuffer, which under Haiku does not work.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12217 a95241bf-73f2-0310-859d-f6bbb57e9c96