DrawingBuffer memory location?

[sq4]

The manual says:

The returned address can be directly in video memory if the output is ScreenOutput() or SpriteOutput() and allows very fast pixel manipulation.

Does this also mean that 2DDrawing/VectorDrawing libs are optimised for both OpenGL/DirectX??? (can't imagine that...)
In my case, p.e., with my old win laptop, and with subsystem OpenGL, I am 100% sure there are transfers from FrameBuffer/Textures to and from CPU/GPU.

Are the PB drawing libs optimised to draw to different subsystems?
Is it dependant of the graphics hardware?
In other words, if I buy myself an up-to-date PC with let's say a mid-range graphics card, will the performance boost!???

Or, is it just pixel manipulation (like peek/poke)?
And if so, are peek/poke wrappers that can access GPU memory?
Or perhaps Point/Plot?

A bit confused here

[Olli]

You only access to the memory dedicated to the video memory.

Through this fact, by getting memory address, you can use CPU instructions to copy and scan the video memory.

The alone way you go faster than the GPU using is the back flow from the video memory to the main memory which is quicker with the CPU statements than the GPU statements could do it.

Excepted this, the GPU being dedicated to handle video memory and to calculate the renderings (texturing, depth, etc...), this GPU should stay the process unit to use.

You can test, and find exceptions where SIMD CPU statements could give good performances, but it is very limited, comparing to a GPU 3D or sprites render.

The basis example is one of these exceptions : using trigonometry to display psychedelic draws. There is a big heap of psychedelic things to be displayed, but a real 3D render requires a strengh process of instructions pre-installed by the GPU.

[sq4]

I think you misunderstood me.

The moment I start using StartDrawing(SpriteOutput()) or StartDrawing(ScreenOutput()), the FPS drops big time.
(I am speaking about subsystem OpenGL)

So, IMHO, this

The returned address can be directly in video memory if the output is ScreenOutput() or SpriteOutput() and allows very fast pixel manipulation.

is a bit misleading.

What's the point of having so called fast access to memory, when the process to get this memory available for access is slow?
I am aware that the GPU/CPU memory pipeline is currently a bottleneck, and that's why that quote in the documentation made me confused.

So, in short : the 2DDrawing lib in PB isn't generating "OpenGL stuff" when drawing in Sprite/Screen output.