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

["Raimar Falke" <i-freeciv-lists@xxxxxxxxxxxxx>]

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

On Sun, Jan 25, 2004 at 07:30:15AM -0800, Jason Short wrote:
> 
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=7301 >
> 
> 
> > You are correct. *looking* It wasn't the case in the old code base
> > which I used for gui-fs (March 2003). I have updated my code version
> > to CVS HEAD some weeks ago. And it still worked and was still slow. So
> > it is/was a problem with too much freedom. I as a client implementor I
> > got the freedom to implement the overview drawing and I did the wrong
> > thing. So with the unification comes a the strict framework what the
> > client has to implement and all the public high-level interface
> > functions are implemented in mapview_common. There is now no way to
> > implement it wrong.
> 
> Now we get to the crux of the problem, however:
> 
> +struct overview {
> +  /* controlled by mapview_common.c */
> +  int map_x0, map_y0;
> +  int width, height;           /* Size in pixels. */
> +  struct canvas_store *store;
> +
> +  /* controlled by mapview.c */
> +  struct canvas_store *window;
> +};
> 
> I don't think you can implement the window in the same way you can do
> the backing store.  Although the backing store is just a fixed-size
> piece of canvas, the window may obey entirely different semantics.
> 
> One problem is that the window may be much larger than the overview, and
> the overview is drawn with an offset.  I believe this is the case in
> gui-win32, and it is certainly the case in gui-sdl.
> 
> Another problem is that in some GUIs the window may not be treated as
> simply another canvas; it has a different drawing interface.  I believe
> this is the case in gui-win32, and it may also be in gui-sdl.
> 
> At a minimum I suspect these problems will mean you'll need a different
> GUI struct for the window (not a canvas_store).
> 
> Note that gui-sdl does not yet use the common overview drawing code so
> you probably won't run into any problems if you compile it.  Nonetheless
> imposing restrictions on the GUI from the common code is quite bad.

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.

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;
};

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.

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.

The abstraction of a generic drawing surface (names "struct
canvas_store" here) is just too powerful to not do it.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Of course, someone who knows more about this will correct me if I'm
  wrong, and someone who knows less will correct me if I'm right."
    -- David Palmer (palmer@xxxxxxxxxxxxxxxxxx)