nanogui: Screen driver development questions


Previous by date: 30 May 2011 22:13:54 -0000 Re: Screen driver development questions, Georg Potthast
Next by date: 30 May 2011 22:13:54 -0000 New to Nano-X: Font problems, Franco Benedetti
Previous in thread: 30 May 2011 22:13:54 -0000 Re: Screen driver development questions, Georg Potthast
Next in thread: 30 May 2011 22:13:54 -0000 Re: Screen driver development questions, Georg Potthast

Subject: Re: [nanogui] Screen driver development questions
From: "Greg Haerr" ####@####.####
Date: 30 May 2011 22:13:54 -0000
Message-Id: <087c01cc1f16$da80fdd0$6964a8c0@winXP>

> I want to extend the scr_djgr screen driver with blit support. In general 
> I understand that there shall be an area of offscreen memory where Nano-X 
> will write the screen data to.

Try copying one of the older screen drivers that had blit support, say
scr_svga.c (SVGA Library).  You will want to implement offscreen
to screen, as well as screen-to-screen support; SVGA only implemented
screen-to-screen (used when dragging windows when HAVEBLIT is defined).



>  When done it will either call xxxx_blit() in version 0.92 to write to the 
> screen or xxxx_update() with the 0.93pre-snapshot version.

The xxx_blit() routine will be called direction in 0.92 with address of 
either
screen memory or offscreen memory.  You're screen driver must allow
access to its memory buffers for this to work.  Your driver will basically
convert between the possibly different screen and offscreen data formats.


> In the open function there is a psd->addr pointer. The scr_X11 driver 
> makes a malloc to assign memory to psd->addr in the open function. 
> However, the scr_svga driver sets this to null.

SVGA lib sets psd->addr to NULL because it doesn't allow access to
any screen memory.  Thus only screen-to-screen copies (blits) are 
implemented.
Otherwise, psd->addr must be malloc'd and all sorts of extra handling
is required in order to keep the screen and psd->addr updated.  This is
not required in 0.93 and was a major reason for the architecture changes.
You can see the ugliness in 0.92 versions of the X11 driver, which are
greatly cleaned up in 0.93.  Basically, X11 had to both draw to the
screen AND keep an internal update of it's malloc'd psd->addr current
on every screen draw entry, drawpoint, drawhline, drawvline, blit etc.



> Both drivers also use gen_allocatememgc() to allocate a second PSD. The 
> scr_svga driver apparently does not need gen_mapmemgc() or gen_freememgc() 
> though to support blitting.

These are complicated by the discussion above.  Use the gen_xxx routines
unless you're going the complex X11-style route.


> The function xxxx_blit() uses a source psd and a destination psd. The 
> xxxx_update() function apparently just gets the source psd and then writes 
> that data to the screen as the final destination.

The Update function is not implentend in 0.92.  When you move to a 0.93
driver, it will be the only function required, and all the above discussion
of extra copying etc, will be no longer required.



> I guess somehow I have to define the offscreen memory for the source psd 
> so I can blit the data to the screen i.e. the destination. Is that done 
> with gen_allocatememgc() and do I have to set psd->addr to null in the 
> open function then? Is gen_mapmemgc() required or can I drop that like the 
> scr_svga driver?

The simplest case is when the screen memory can be directly accessed, then 
use gen_xxx
routines.  Otherwise, go the X11 route with custom handlers for everything, 
and
complex entry points that draw and copy.

> Is all this done differently with version 0.92 versus the snapshot 
> version?

Yep!

Regards,

Greg







Georg


Previous by date: 30 May 2011 22:13:54 -0000 Re: Screen driver development questions, Georg Potthast
Next by date: 30 May 2011 22:13:54 -0000 New to Nano-X: Font problems, Franco Benedetti
Previous in thread: 30 May 2011 22:13:54 -0000 Re: Screen driver development questions, Georg Potthast
Next in thread: 30 May 2011 22:13:54 -0000 Re: Screen driver development questions, Georg Potthast


Powered by ezmlm-browse 0.20.