Complete.Org: Mailing Lists: Archives: freeciv-dev: January 2004:
[Freeciv-Dev] Re: (PR#7301) Unified and cached overview
Home

[Freeciv-Dev] Re: (PR#7301) Unified and cached overview

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: undisclosed-recipients: ;
Subject: [Freeciv-Dev] Re: (PR#7301) Unified and cached overview
From: "Raimar Falke" <i-freeciv-lists@xxxxxxxxxxxxx>
Date: Tue, 27 Jan 2004 02:19:46 -0800
Reply-to: rt@xxxxxxxxxxx

<URL: http://rt.freeciv.org/Ticket/Display.html?id=7301 >

On Mon, Jan 26, 2004 at 10:55:21PM -0800, Jason Short wrote:
> 
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=7301 >
> 
> > [i-freeciv-lists@xxxxxxxxxxxxx - Mon Jan 26 08:18:23 2004]:
> 
> > This is wrong. First window doesn't imply a window in the GTK or X11
> > sense. A window here is the on-screen drawing surface while the store
> > field is the off-screen drawing surface.
> 
> Window implies a window in the gdk sense.  But this only works if the
> GUI code uses a corresponding abstraction.  There's no reason to think
> it does.

Please reread. A window here is a part of the on-screen drawing
surface. Its implementation may a simlpe GdkPixmap in the gtk1 client
or something like:
  SDL_Surface *whole_screen;
  struct rect *window_area;
for the SDL case
  
> > About different drawing interfaces: this also not an issue since the
> > canvas store may look like:
> > 
> > struct canvas_store {
> >   bool is_off_screen;
> >   union {
> >     struct {
> >       fields for off_screen drawing
> >     } off_screen;
> >     struct {
> >       fields for on_screen drawing
> >     } on_screen;
> >  } data;
> > };
> 
> Yes, but that's quite ugly.

I agree but it will make the common code quite nice and also the
gtk1,gtk2,xaw and fs client.

> Why have a union when we already know whether the store is offscreen
> or not?

Because we only want one set of drawing functions (gui_put_*).

> I think we want two separate structures for this - it will help a
> lot in typecasting.

I don't think so.

> Although I'm not as sure of this as I was before.
> 
> > For example it is possible that you only have one on-screen
> > surface. Than you would put the boundaries of this particular "window"
> > into the off-screen drawing fields.
> 
> Quite possible.  But I still don't see how you would control alpha-layer
> drawing.

Honestly I haven't looked at the sdl client and I don't know how it
does the transparency thing. But I think that this abstraction is
general enough. One solution could be to do something like:

...
struct {
  SDL_Surface *whole_screen;
  struct rect *window_area;
  int transparency.
} on_screen;
...

> > All of this is easy to do. But I agree that it may be more work for
> > clients. At least gtk1, gtk2, xaw and fs however doesn't have a
> > problem here. This leaves win32, sdl and mui.
> 
> You should test this with win32 and sdl clients.  For large changes I've
> always done this in the past.  This is why such changes are difficult.

I can't compile the win32 client and I can't get the sdl client to
run. Sorry.

> > The abstraction of a generic drawing surface (names "struct
> > canvas_store" here) is just too powerful to not do it.
> 
> I agree.  But we need an abstraction that will work in all cases.

There is another alternative. One where you don't seperate between
off-screen and on-screen. I have used this alternative for gui-fs. All
drawing is done to off-screen areas. There is only one function to
copy part of this off-screen-area to the screen. Not sure if this is
better.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 A life? Cool! Where can I download one?




[Prev in Thread] Current Thread [Next in Thread]