nanogui: More on Image handeling and optimizations
Subject:
RE: More on Image handeling and optimizations
From:
Greg Haerr ####@####.####
Date:
25 Jan 2000 18:38:51 -0000
Message-Id: <C1962B36D9BBD311B0F80060083DFEFB041951@SYS.CenSoft.COM>
: I'd like
: to see antialiased fonts on top of a background image in Opera...
: This needs full alpha blending (which BTW I'd love to see some
: MMX code for... current implementation is neither fast, nor
: extremely accurate. And it uses semi-large tables.)
I spent the whole weekend coming up to speed on alpha
blending. I will have a version for Microwindows out immediately
after 0.87. We will support alpha blending for 16bpp and 32bpp
directly, as well as producing RGB->palette index conversion
tables for 8bpp systems. (I have to make the 8bpp work,
since that's the only mode I can get my damn framebuffer
to operate in). The table sizes for 8bpp will total 64k. No
tables are required for 16bpp or 32bpp truecolor.
In the beginning I plan to support constant alpha
blending for an entire image, as well as per-pixel
alpha blending with 24bpp images, with the alpha
channel in an additional 8bpp.
:
: I have been thinking of requiring word or dword padding
: on GrArea as well - better safe than sorry.
It would probably be a good idea to require dword padding now.
then we would have a common format for all monochrome
and color images within Microwindows, and the data could
be used between all routines...
:: Hmm, in my world this smells too much like X11 with its
: memory management problems (fragmentation). We are going
: to use it in an environment where there may be
: *absolutely* **no** more memory left at some point, which
: means that the nano-X server should ideally allocate and
: touch all the pages it will need when it starts off, and
: never look back WRT memory.
:
: Would this be feasible today? How much dynamic allocation
: is there in nano-X? I was thinking of just doing:
:
This is a problem. Microwindows, being message oriented,
doesn't allocate any space for events, it just passes messages.
Nano-X, however, is constantly allocating space for client
connections and event structures.
In addition, with the new clipping code, we will be moving
towards dynamic rectangle allocations. [Yes, you can use
the old clipping...]
I don't think it will be easy to meet your specific zero-memory
after initialization need...
: Yes... But we will probably not get around this completely
: anyway - ie. doing word aligned memcopy on an 8 bit display
: would restrict your choices on where to put the image...:-)
No - the DWORD padding just ensures that the source
bitmap is aligned for high-speed access across cache lines,
etc. Images are NOT restricted to multiples of the padding, and
the copy to the destination isn't restricted either. This is
just a speed issue, not a limitation on size or placement.
:
: Yes, but *inter* device blitting? (Blitting from one gfx card
: to another...?)
That's a horse of a different wheelbase. Adding plans for
multiple graphics cards is probably not something
Microwindows will do in the near future.
:
: If doing GrArea with blit, we need to setup a suitable psd for the
: operation on every call to GrArea, which is kind of not needed.
: One could pre-allocate a memory psd and only update the bits inside
: it that are relevant to the blit in question, but this is kind of
: an unclean situation. I'd like the device-drivers and the memory
: driver to fiddle with the internals of the psd as much as possible,
: and not the engine code?
:
I've already accomplished this, but you may not have noticed.
The first 10 words of a SCREENDEVICE are exactly what you're
looking for. The difference is that the function pointers are also
included, so that another level of indirection isn't required.
I haven't finished all the work with the function pointers, though.
Regards,
Greg
