For fast graphics like full motion video or action games, we will need support
for shared memory access to bitmaps. If an application can get fast access to
the contents of a bitmap, it can use this bitmap in the canvas widget to draw
to the screen very fast. In addition, the display itself is a bitmap so an
application could request direct access to the display for fullscreen graphics.
This functionality could be provided by an API function similar to this:
char *pgMMapBitmap(pghandle bitmap);
Using shared memory, the client could draw directly into pgserver's memory
storing this bitmap. This will not be network transparent- this API should
cause an error, or maybe perform some kind of emulation using sockets if the
pgserver is on a different computer.
The problem with writing directly to memory though is that all bitmaps in
PicoGUI are stored in a device-dependant format. A couple of things we could do
to solve this:
- Provide a new data type for a Device Independant Bitmap that can only be
mmap'ed and converted into a device-dependant bitmap. This way, apps can work
with RGB data and have it converted into the device's format. This wouldn't be
that fast, but it would be portable.
- Allow the app to get information about the hardware-dependant bitmap format.
There could be a number of constants describing different formats, like 2-3-3
RGB (used on the TuxScreen), 1- 2- and 4-bpp grayscale, true color, etc. Some
drivers may use a nonstandard hardware format (like ncurses) or shouldn't allow
the client to modify raw colors (ez328vga).
This will only serve to get the client app a pointer to the raw bitmap data. It
would probably be useful to provide a higher-level interface to that. As a good
existing standard, maybe we could implement support for PicoGUI graphics in SDL?
Quoting John Laur <[EMAIL PROTECTED]>:
> On a similar note, what would be the best way to blit something like
> video onto the display? What kind of special things need to be
> implemented to have something akin to full motion video?
>
> John
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] On Behalf Of Micah
> Dowty
> Sent: Monday, October 22, 2001 11:53 AM
> To: Olivier Bornet
> Cc: PicoGUI Devel
> Subject: Re: [Pgui-devel] Primitive for displaying fast a RGB buffer
>
> PicoGUI's pgNewBitmap function can handle this. It supports the PPM
> format,
> which is just 24-bit RGB data with a small header. Here's an example
> of
> generating an RGB bitmap at runtime:
>
> ------8<------
> /* Demonstration of loading RGB pixel values as a bitmap in PicoGUI */
>
> #include <picogui.h>
> #include <malloc.h>
>
> /* Build a 24-bit PPM file with a 2D gradient */
> pghandle gradient_bitmap(void) {
> char *pnmfile,*bitdata,*p;
> int w,h,x,y;
> long size;
>
> /* Allocate memory to construct our bitmap in */
> w = 255;
> h = 255;
> size = w * h * 3 + 20; /* 20 is space for our header */
> pnmfile = malloc(w * h * 3 + 20);
>
> /* Write the header for a binary 24-bit PPM file */
> bitdata = pnmfile + sprintf(pnmfile,"P6 %d %d 255\n",w,h);
>
> /* Draw some colors in our bitmap */
> p = bitdata;
> for (y=0;y<h;y++)
> for (x=0;x<w;x++) {
> *(p++) = 0; /* Red */
> *(p++) = x; /* Green */
> *(p++) = y; /* Blue */
> }
>
> /* Allocate a picogui bitmap, freeing our buffer */
> return pgNewBitmap(pgFromTempMemory(pnmfile,size));
> }
>
> /* Make an app to show our bitmap in */
> int main(int argc, char **argv) {
> pgInit(argc,argv);
> pgRegisterApp(PG_APP_NORMAL,"RGB Bitmap Test",0);
> pgNewWidget(PG_WIDGET_BITMAP,0,0);
> pgSetWidget(PGDEFAULT,
> PG_WP_SIDE,PG_S_ALL,
> PG_WP_BITMAP,gradient_bitmap(),
> 0);
> pgEventLoop();
> return 0;
> }
> ------>8------
>
> Also: In Waba, isn't this function mainly used for loading BMP format
> data?
> PicoGUI is now capable of loading BMP data in pgNewBitmap(), so you
> should be
> able to bypass Waba's built-in BMP decoder and just send the BMP file
> itself to
> pgNewBitmap().
>
>
>
> Quoting Olivier Bornet <[EMAIL PROTECTED]>:
>
> > Hello,
> >
> > I want to display a RGB buffer I have in memory (let's call it
> > rgbbuf).
> > The buffer consist of an array of the red, green and blue values of
> > each
> > pixel (red1, green1, blue1, red2, green2, blue2, red3, green3,
> blue3,
> > ...). No separation are made for lines break. I just know the width
> > (w)
> > and height (h) of the bitmap.
> >
> > I can do it with something like :
> >
> > pos = rgbbuf;
> > for( myY = 0; myY < h; myY++ ) {
> > for( myX = 0; myX < w; myX++ ) {
> >
> > myColor = ((pgcolor *)pos)[ 0 ];
> > pos += 3;
> >
> > pgSetColor( gc, myColor );
> > pgPixel( gc, x + myX, y + myY );
> >
> > }
> > }
> >
> > But this is slow. The slowing part is to make every time the
> > pgSetColor() and pgPixel(). I have try to go trough a bitmap in
> > memory,
> > but without significant improvement.
> >
> > In gtk, we have the function gdk_draw_rgb_image() for this.
> >
> > Thanks in advance.
> >
> > Olivier
> > --
> > Olivier Bornet SMARTDATA SA
> > [EMAIL PROTECTED] Centre du Parc
> > http://www.smartdata.ch av. des Pr�s-Beudin 20
> > Phone +41-27-723'55'03 1920 Martigny
> > Fax +41-27-723'55'19 Phone +41-27-723'55'18
> >
> > _______________________________________________
> > Pgui-devel mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/pgui-devel
> >
>
>
>
> --
> Only you can prevent creeping featurism!
>
> _______________________________________________
> Pgui-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/pgui-devel
>
>
> _______________________________________________
> Pgui-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/pgui-devel
>
--
Only you can prevent creeping featurism!
_______________________________________________
Pgui-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/pgui-devel
