Subject:
Re: Multiple famebuffer
From:
Jordan Crouse ####@####.####
Date:
20 Nov 2000 15:05:42 -0000
Message-Id: <3A193D88.CC089021@censoft.com>
> Yeah, it's just that we save a blt from user to kernel space. Having two
> fbs with hardware support to set the lcd memory start address makes
> double buffering really fast, no?
Well, like Einstein said, its all relative. Either way you look at it,
the memory copy is going to be your fastest option.
It *is* a little faster to copy between two addresses in kernel memory,
but not by much.
Is the extra time that it takes to go from user to kernel space that
critical in your application? If you are getting that critical,
I would suggest that you should start looking into hardware accelerated
bliting, because really, that will be the only thing faster
than using a pixmap blit.
> Look forward to seeing this... Having two fbs saves some processing
> overhead, which might be relevant on the hardware we're on. You think
> it's not worth the effort?
I don't understand where having two FBs would save you the overhead. I
mean, even tossing out the speed factor and the
kernel overhead (plus the additional overhead that Microwindows needs to
manage two framebuffer devices), and look at two things.
First, if you use two framebuffers, both will have to be available
before you start the server, meaning that you will have to
take up the memory somewhere, and keep it there for the life of the
server. Regardless of where it lives, that still means you will
have to do without 307K (640 x 480 = 307200 bytes). With the pixmap
however, you can choose how much memory to allocate, and it can
be dynamically allocated and removed during the life of your program.
You don't need to allocate the whole screen space, just the bytes
you need. That alone should be more attractive than a whole new
framebuffer.
Of course, I don't know exactly what this hardware is for, and how it
will be used. Maybe you have a limited amount of
user memory, or maybe you need excellent performance out of your drawing
routines. That will be up to you to
sit down and examine exactly what you need.
I know Kim is working on a SH3 based device (and I assume you are too),
and I know
that everyone is excited to see Microwindows work on a new processor
(lets see X do that!! :-)), so I want to make sure that
you guys don't have to do any unnecessary work. If a second framebuffer
is the best solution, then I wish you much
luck, because I don't believe it will be easy to get it working, but if
you do, I am sure that the rest of us on the list
will be very excited to see what you have done.
Good luck!
Jordan
>
> Marc
>
> >
> > Marc Nijdam wrote:
> > >
> > > The way Kim (co-worker of mine) is set up now we're looking at having
> > > multiple framebuffers fb0 and fb1, and would like to get microwindows
> > > use those for double buffering. Is this harder? I guess not, since you
> > > just wouldn't use GrPixmap() but the other fb device to build a
> > > GR_WINDOW_ID instead?
> > >
> > > Cheers,
> > >
> > > Marc Nijdam
> > >
> > > Jordan Crouse wrote:
> > > >
> > > > Ok, now I understand whats going on. You want to double buffer your
> > > > screen, not display to multiple framebuffers.
> > > >
> > > > Thats easy. Just use GrNewPixmap() to create a offscreen "window" that
> > > > you can draw into, just like a real window. Then, when you're ready,
> > > > use GrCopyArea to blit the pixmap area to the screen. For example, here
> > > > I draw a rectangle in the pixmap and then put it on screen:
> > > >
> > > > GR_WINDOW_ID foo = GrNewPixmap(15, 15, NULL);
> > > > GrSetGCForeground(gc, BLUE);
> > > > GrFillRect(foo, gc, 5,5, 5, 5);
> > > >
> > > > GrCopyArea(GR_ROOT_WINDOW_ID, gc, 5, 5, 5, 5, foo, 0, 0, MW_SRCCOPY);
> > > > GrDestroyWindow(foo);
> > > >
> > > > Hope that helps.
> > > > Jordan
> > > >
> > > > "KIM,KYOUNG-IL (HP-Cupertino,ex1)" wrote:
> > > > >
> > > > > Thank you for advice.
> > > > > My question is if Microwindows can use double(triple) framebuffers
> > > > > and compare difference between buffers and update only difference
> > > > > into dispay buffer. I know there was discussions and I don't know
> > > > > how it gose now.
> > > > >
> > > > > Thank you,
> > > > > Kyoung Kim
> > > > >
> > > > > -----Original Message-----
> > > > > From: Alex Holden
> > > > > To: KIM,KYOUNG-IL (HP-Cupertino,ex1)
> > > > > Cc: ####@####.####
> > > > > Sent: 11/16/00 1:30 AM
> > > > > Subject: Re: Multiple famebuffer
> > > > >
> > > > > On Wed, 15 Nov 2000, KIM,KYOUNG-IL (HP-Cupertino,ex1) wrote:
> > > > > > Can Microwindows(Win32 or Nono-X) handle multiple frame buffers ?
> > > > >
> > > > > Not currently. There was some talk recently of adding support for
> > > > > multiple
> > > > > displays; try searching the mailing list archive if you're interested
> > > > > <http://www.linuxhacker.org/lists.phtml>
> > > > >
> > > > > --
> > > > > ------- Alex Holden -------
> > > > > http://www.linuxhacker.org/
> > > > > http://www.robogeeks.org/
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: ####@####.####
> > > > > For additional commands, e-mail: ####@####.####
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: ####@####.####
> > > > > For additional commands, e-mail: ####@####.####
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: ####@####.####
> > > > For additional commands, e-mail: ####@####.####
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: ####@####.####
> > For additional commands, e-mail: ####@####.####
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
