nanogui: Thread: Drawing modes

After spending a while reading the Allegro code, though I don't really
understand the bank code (it seems to be to do with making sure
transactions are properly aligned), it does appear that all the drawing
modes except plain old "set", do in fact read from the buffer, perform the
operation, and then write it back. So if you do an XOR draw to the Frame
buffer, for every pixel you write it reads one from the graphics device
first (well, the banking code will speed things up for hlines() if I
understand it right by reading several pixels at once, but you get the
idea). That doesn't stop you from allocating a memory buffer, performing
the operations on that, and blitting the altered regions to the screen
buffer if you want, but that isn't the way it works normally. I'm going to
get some sleep now, but I'll probably write the other drawing modes when 
I get up in the morning.

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------

On Tuesday, May 18, 1999 6:44 PM, Alex Holden ####@####.#### wrote:
> After spending a while reading the Allegro code, though I don't really
> understand the bank code (it seems to be to do with making sure
> transactions are properly aligned)

	The allegro bank code is some of the most *ingenious* code in
allegro, and is the basis for the trickery to make screen graphics memory
and offscreen graphics memory work the same with common drawing code.

It has nothing to do with allocating a separate buffer, and blitting.  This is far
too expensive.  Instead, the idea is, that all graphics primitives work on a "BITMAP *"
structure.  This structure has both a start memory address, and a set of
banking code proc ptrs.  All of the drawing primitives (of which bitblt is also
one) then draw onto the memory address in the BITMAP *.  This writes bits
in either screen memory or offscreen memory.  The trick is, that the bank
switch code for graphics memory actually switches graphics memory banks,
required by the hardware, while offscreen memory is instead "offseted" by
the total bank size, and the bits drawn there.  Cool, huh?



, it does appear that all the drawing
> modes except plain old "set", do in fact read from the buffer, perform the
> operation, and then write it back. So if you do an XOR draw to the Frame
> buffer, for every pixel you write it reads one from the graphics device
> first (well, the banking code will speed things up for hlines() if I
> understand it right by reading several pixels at once, but you get the
> idea).

	Don't get confused by the "read-modify-write" cycle that the EGA/VGA
controllers require for the damned hardware.  It think this is what you're looking
at.  The EGA/VGA doesn't require an rmw cycle for XOR, it requires it for all
writes, and the SET, AND, OR, XOR stuff is controlled in yet another hw register.



 That doesn't stop you from allocating a memory buffer, performing
> the operations on that, and blitting the altered regions to the screen
> buffer if you want, but that isn't the way it works normally.

	Think of blit as yet another drawing primitive, not the only one.


 I'm going to
> get some sleep now, but I'll probably write the other drawing modes when 
> I get up in the morning.
> 
> --------------- Linux- the choice of a GNU generation. --------------
> : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
> -------------------- http://www.linuxhacker.org/ --------------------
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 

> 	The allegro bank code is some of the most *ingenious* code in
> allegro, and is the basis for the trickery to make screen graphics memory
> and offscreen graphics memory work the same with common drawing code.
> 
> It has nothing to do with allocating a separate buffer, and blitting.  This is far
> too expensive.  Instead, the idea is, that all graphics primitives work on a "BITMAP *"
> structure.  This structure has both a start memory address, and a set of
> banking code proc ptrs.  All of the drawing primitives (of which bitblt is also
> one) then draw onto the memory address in the BITMAP *.  This writes bits
> in either screen memory or offscreen memory.  The trick is, that the bank
> switch code for graphics memory actually switches graphics memory banks,
> required by the hardware, while offscreen memory is instead "offseted" by
> the total bank size, and the bits drawn there.  Cool, huh?
> 

	The other cool thing that allegro does that I've been thinking about
for a major driver design enhancement for nano-X, is that, using the above
routines, the offscreen bitmaps are drawn using the same bit-plane ordering
as the device memory.  (Of course, since it's using the same code).  Then,
when an offscreen bitmap wants to be displayed, it can be quickly bitblt'd, with
out plane adjustment for speed.

	Currently, nano-x (mini-x api) doesn't support any means of programmatically
drawing to anything other than the screen.  This can be a problem if, for instance,
an area needs to be background erased and then much of it written over again
with new contents.  This will cause annoying flashes.  Instead, there needs to be
a capability of executing both draws to offscreen bitmaps, and then a single bitblt
to the screen.

	One more thing that could be cool about a design like this.  "Pseudo-graphics"
drivers can be created, which essentially know about other common screen formats
(read color bitmap formats) and then these binary formats can be easily imported
and exported from the nano-X system.

Comments?

Greg

Greg Haerr ####@####.#### writes:

	   One more thing that could be cool about a design like this.  "Pseudo-graphics"
   drivers can be created, which essentially know about other common screen formats
   (read color bitmap formats) and then these binary formats can be easily imported
   and exported from the nano-X system.

This is where a generic any-bit-depth driver is especially valuable.
-- 
"To the engineer, the world is a toy box full of sub-optimized and
 feature-poor toys." --Scott Adams

On Wednesday, May 19, 1999 12:06 PM, Ben Pfaff ####@####.#### wrote:
> Greg Haerr ####@####.#### writes:
> 
> 	   One more thing that could be cool about a design like this.  "Pseudo-graphics"
>    drivers can be created, which essentially know about other common screen formats
>    (read color bitmap formats) and then these binary formats can be easily imported
>    and exported from the nano-X system.
> 
> This is where a generic any-bit-depth driver is especially valuable.

	Is this what you're trying to do with the new bogl drivers using the variable
byte-putting procedures?

	This is more what I was suggesting when I talked about trying to combine
all the bogl 8/16/24/32 bit drivers into one, for maintainability.

Greg




> -- 
> "To the engineer, the world is a toy box full of sub-optimized and
>  feature-poor toys." --Scott Adams
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 
> 

On Wed, 19 May 1999, Greg Haerr wrote:
> 	Don't get confused by the "read-modify-write" cycle that the EGA/VGA
> controllers require for the damned hardware.  It think this is what 
> you're looking at.  The EGA/VGA doesn't require an rmw cycle for XOR, it
> requires it for all writes, and the SET, AND, OR, XOR stuff is
> controlled in yet another hw register.

Since you keep insisting that it is possible to get around the requirement
to do RMW, I've looked hard for any code which demonstrates this, but I'm
sorry to say I've been unable find any. As an example, here is an extract
from __linear_putpixel8 (the basis of pretty much all operations on 8 bit
linear devices- the other bit depths all seem to work the same way) from
allegro:

putpix_xor_mode:
   READ_BANK()                   /* read pixel from screen */
   xorb %es:(%eax, %ecx), %bl    /* XOR */
   movl ARG3, %eax               /* re-read Y position */
   jmp putpix_solid_mode
 
Surely it reads it from the screen, modifies it, then writes it back?

I've also looked hard at the GGI, W, and X low level framebuffer drivers,
and none of them even seem to even implement different draw modes. I've
looked at the kernel side code, and was unable to see any way to write to
a graphics device in anything other that the ordinary SET mode, though it 
is pretty complex and I could have overlooked something.

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------

On Wednesday, May 19, 1999 1:21 PM, Alex Holden ####@####.#### wrote:
> On Wed, 19 May 1999, Greg Haerr wrote:
> > 	Don't get confused by the "read-modify-write" cycle that the EGA/VGA
> > controllers require for the damned hardware.  It think this is what 
> > you're looking at.  The EGA/VGA doesn't require an rmw cycle for XOR, it
> > requires it for all writes, and the SET, AND, OR, XOR stuff is
> > controlled in yet another hw register.
> 
> Since you keep insisting that it is possible to get around the requirement
> to do RMW, I've looked hard for any code which demonstrates this, but I'm
> sorry to say I've been unable find any. As an example, here is an extract
> from __linear_putpixel8 (the basis of pretty much all operations on 8 bit
> linear devices- the other bit depths all seem to work the same way) from
> allegro:
> 

	I'm not talking about the linear modes, they're easy, and of course
you have to read, xor, and write.

	I'm talking about the planar modes, which are a pain in the ass.
I thought you were working on the vga16 driver, which uses the planar modes.
In the planar mode, the hardware is setup the way I've been describing.




> putpix_xor_mode:
>    READ_BANK()                   /* read pixel from screen */
>    xorb %es:(%eax, %ecx), %bl    /* XOR */
>    movl ARG3, %eax               /* re-read Y position */
>    jmp putpix_solid_mode
>  
> Surely it reads it from the screen, modifies it, then writes it back?
> 
> I've also looked hard at the GGI, W, and X low level framebuffer drivers,
> and none of them even seem to even implement different draw modes.

	I don't doubt they may be hidden.  I haven't had a chance to look
at the drivers you sent me.  Does X support a framebuffer driver for the vga 16-color
planar mode, or just the linear modes?

 I've
> looked at the kernel side code, and was unable to see any way to write to
> a graphics device in anything other that the ordinary SET mode, though it 
> is pretty complex and I could have overlooked something.

	In the planar drivers that I've seen, sometimes all the MODE_SET stuff
is hidden in an entirely separate proc that sets up the VGA hardware to automatically
do the XOR etc without having to write code for it per pixel.

> 
> --------------- Linux- the choice of a GNU generation. --------------
> : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
> -------------------- http://www.linuxhacker.org/ --------------------
> 

On Wed, 19 May 1999, Alex Holden wrote:
> I've also looked hard at the GGI, W, and X low level framebuffer drivers,
> and none of them even seem to even implement different draw modes. I've

I just looked at ClanLib, and that's the same. Just normal and transparent
(where a particular colour doesn't get blitted) draw modes.

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------

On Wed, 19 May 1999, Greg Haerr wrote:
> 	I'm not talking about the linear modes, they're easy, and of course
> you have to read, xor, and write.

Okay, I didn't realise that.

> 	I don't doubt they may be hidden.  I haven't had a chance to look
> at the drivers you sent me.  Does X support a framebuffer driver for
> the vga 16-color planar mode, or just the linear modes?

I think so, the code is pretty difficult to follow. Actually I later
realised that the stuff I sent you isn't all of the driver, just the
generic frame buffer code (for frame buffers on any kind of graphics card,
rather than specifically the Linux frambuffer).

> 	In the planar drivers that I've seen, sometimes all the MODE_SET stuff
> is hidden in an entirely separate proc that sets up the VGA hardware to
> automatically do the XOR etc without having to write code for it per
> pixel.

I'll look into it.

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------

On Wednesday, May 19, 1999 2:05 PM, Alex Holden ####@####.#### wrote:
> On Wed, 19 May 1999, Alex Holden wrote:
> > I've also looked hard at the GGI, W, and X low level framebuffer drivers,
> > and none of them even seem to even implement different draw modes. I've
> 
> I just looked at ClanLib, and that's the same. Just normal and transparent
> (where a particular colour doesn't get blitted) draw modes.

	You might also look at the original mini-x source, or the new stuff,
and look at the files kernel/graph_ega.c, and kernel/ega.x.  This shows what the
mini-x driver does on GC's that expect XOR draw modes.  In the mini-x ega
driver, there's a single little procedure, ega_setmode, that sets up the hw.

	I'm pretty certain that we've got to implement the XOR modes, or the
samples won't work.  (including the cool new one, world)

	What is ClanLib?

Greg



> 
> --------------- Linux- the choice of a GNU generation. --------------
> : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
> -------------------- http://www.linuxhacker.org/ --------------------
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>