Subject:
Re: Multiple famebuffer
From:
Marc Nijdam ####@####.####
Date:
21 Nov 2000 03:01:35 -0000
Message-Id: <3A19E46A.E8774B54@hp.com>
Jordan Crouse wrote:
>
> > 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.
If I draw to one fb, which is currently displayed by the hw, then draw
to the other one, and point the hw with a single instruction at the new
fb mem area, does that make it faster? No copies required, right?
Marc
> 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: ####@####.####
