Subject:
RE: More on Image handeling and optimizations
From:
Greg Haerr ####@####.####
Date:
21 Jan 2000 18:40:54 -0000
Message-Id: <C1962B36D9BBD311B0F80060083DFEFB0416AF@SYS.CenSoft.COM>
: Please note that currently, the GdArea/GrArea functions are
: very important to us and Opera, and may be even more so if
: Vidar decides to use GdArea in his efforts to beat X11 in
: the font rendering game...
According to Vidar's last email, he already is using
GdArea for *fantastically cool anti-aliased better-than-X11*
font rendering.
Which means I'll make GrArea fast and
: flexible, or use other means like Blit if this is considered
: better. I'm worried the Blit function may end up being too
: flexible, large, and hard to optimize, though.
A couple of words about blit: at it's core, all a SRCCOPY
blit is supposed to do is copy a rectangle of
memory from one location to another, FAST. Ideally,
the src and dst pixel packings are the same, and
no conversion occurs. Then, the bigger issue
is whether the src and dst image "line length" values
are enforced for all images. For instance, if the
framebuffer video screen is "word padded", while
user images are allowed to be submitted as only
"byte padded" (no padding), then an optimized
word-by-word memory copy cannot be used for
highest speed. In Windows, _all_ images are
required to be DWORD padded, so that the fastest
dword-by-dword memory copy routines can always be
used. If we used this convention, that would mean
that all GrArea/GdArea images would have to be
DWORD padded or they couldn't be used.
I'd like comments on the above... Currently,
Microwindows requires WORD padding
on bitmap images, and no padding on GrArea
images.
: 1) Tiling of images. Painting a non-uniform background
: can be done with tiles, which would reduce the client
: to server overhead a lot (e.g. only transfer the
: single smaller image). I envision this to be a feature
: of GrArea.
I would suggest that, rather than making this a special
feature of GrArea, that the concept of server-side
images, with associated IDs, be introduced. Then a
special tile function could be used with that ID.
:
: 2) It should be possible to do sub-imageing on the client
: side by GrArea without temporary storage, e.g. the
: application wants to take a small piece out of a larger
: image and paint it on the screen. This could be relevant
: when repainting only parts of a large image for example.
: By having the client side extract only the pixles needed,
: the transfer is more efficient.
I'm not quite sure what you're looking for here. Are you
talking about wanting to just paint a sub-rectangle
of client side image bits? Just modify the x,y,w,h
of the original GrArea. [Note this has big problems
if we move to high-speed DWORD padding of images]
:
: 3) Alpha blending. Yeah. It's definite, I've gone mad.
: Not something for the faint of heart, or 286 projects,
: but it would make Nano-X rock as a high quality
: environment.
I would _love_ to do alpha blending. Both MAC OS X
and Windows 2000 are supporting it. I'm definitely
interested in supporting it. Actually, after checking out
screen shots for both the above, I decided I was
going to write it!
:
: I'm not sure where this should be done, though. It probably
: belongs in the Blit function, which would grow large
the blit functions are all going to get bigger when we
start supporting something other than just the simple
SRCCOPY.
: I have a concern for the Blit function:
:
: Is it future-proof to require the destination 'psd' to do the
: operation? What if the source 'psd' is better suited for the
: job? I'm probably thinking device-device bliting where none
: of the devices are memory, which is probably not supported yet,
We already support device-device blitting. I currently use
screen-to-screen blitting to implement the scrolling for the terminal
emulator demos.
:
: I have extended the existing code with a psd->DrawArea function,
: with a couple of emulation functions, and it seems to work like
: a charm. Should I continue this or try to integrate with Blit?
: Changing the low level part to Blit later on should be easy, but
: we may better experiment and figure out what is needed when they
: are separate. Comments?
I'd like to see your code. But I'd also like to see the GdArea
code using blit, since we already have written (and now debugged)
1, 2, 4, 8, 16 and 32bpp blit drivers. [not all are fast].
So, both.
Regards,
Greg
