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

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: i-freeciv-lists@xxxxxxxxxxxxx
Subject: [Freeciv-Dev] (PR#7301) Unified and cached overview
From: "Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 26 Jan 2004 22:55:21 -0800
Reply-to: rt@xxxxxxxxxxx

<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.

> 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.  Why have a union when we already know
whether the store is offscreen or not?  I think we want two separate
structures for this - it will help a lot in typecasting.

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.

> 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.

> 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.

jason



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