Dear Jiri,
I apologize for my untimely reply.
Semi-transparent windows are rather easy. It would be near trivial to
enable color-key transparency for windows. Alpha transparency only
requires adding alpha channel to the bitmap structure.
Great!
To allow 'generic' transforms, you would need to replace the simple
translation with 'generic' transform in the ds_window structure, the
paint routine and the event transform code. It's pretty straightforward.
There is nothing that would make this impossible or even difficult. I
simply decided against implementing it because I didn't deem it worth
the extra work and added code complexity. It could be done based on
actual use case. I'd like to avoid this feature creating much overhead
when not used, so I'd prefer having a special 'fast' case when simple
translation can be used (and possibly completely opting out of
transforms at compilation time). I simply didn't feel like adding all
this complexity without actually putting it to some practical use.
OK, makes sense.
In any case general transforms are quite difficult to implement
efficiently without appropriate HW acceleration, which is currently
nowhere in sight. (and given our manpower and focus might quite frankly
never happen).
It is surely difficult, but it is doable. And with the power of current
CPUs, it is even practically usable. I am often amazed what the Gallium
LLVMpipe or the generic SVGA driver in Windows 10 can do on a completely
unaccelerated framebuffer.
Many current GPUs do not have dedicated blitters
and other 2D acceleration facilities, everything is handled by the 3D
engine.
You would need to explain more what difference that makes from software
standpoint, I'm not sure what actually concerns you.
I think it is simply a terminological difference.
For me, a blitter (*) is a specific DMA engine that can copy memory
ranges while skipping parts of the input and output scanlines. No
filtering, no transformations (maybe except supporting bit masks). Even
the support for tiled framebuffers is usually not included and needs to
be done by running several operations.
This is the sort of specific operation that has been implemented by the
early HW 2D accelerated graphics. Obviously, current GPUs use much more
advanced and complex mechanisms and therefore the use of the term
"blitter" as a genericized term for all HW acceleration might be
misleading (creating the impression that the design cannot really
accommodate anything beyond a blitter).
(*) Coming from blit, bitblt, bit-block transfer.
Do not cling to
the expression "HW blitters", what I had in mind was HW acceleration in
general. Since currently the only graphics operation that we could use
acceleration for is blitting bitmaps, it could well be carried on a good
old fashioned SVGA blitter or by the 3D engine of a GPU (while I can
image the former being easier to implement, but obviously less widely
useful).
My point exactly.
M.D.
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel
