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

["Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

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

jason