[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 Tue, Jan 27, 2004 at 09:37:45AM -0800, Jason Short wrote:
> 
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=7301 >
> 
> > [i-freeciv-lists@xxxxxxxxxxxxx - Tue Jan 27 10:29:27 2004]:
> > 
> > On Mon, Jan 26, 2004 at 10:57:43PM -0800, Jason Short wrote:
> > > 
> > > <URL: http://rt.freeciv.org/Ticket/Display.html?id=7301 >
> > > 
> > > > [i-freeciv-lists@xxxxxxxxxxxxx - Mon Jan 26 08:36:38 2004]:
> > > 
> > > > Also note that in the FS client an expose doesn't destroy the image
> > > > drawn onto a canvas. The reason is that the FS client has an "expose
> > > > buffer" for the whole screen. (This is also nice for doing screen
> > > > dumps.)  So with this you will encode client specific mechanism into
> > > > the common code.
> > > 
> > > But what you're doing also encodes a client-specific mechanism into the
> > > common code, since if an additional blit IS required it's not easy for
> > > the GUI code to do it.
> > 
> > I don't understand. What additional blit? The FS one? This isn't done
> > by common client code nor by FS client code nor by the widget code. It
> > is done by the backend. Every drawing is done to an off-screen buffer
> > which holds the whole screen image. This buffer is then copied to the
> > screen. This is done by request (when the widget code redraws a
> > widget) or when an expose event arrives.
> 
> In the current GTK client the blit goes directly to the widget's GDK
> window.  This basically means it goes directly to the screen.
> 
> But a more efficient GTK client implementation would have another
> backing store.  In this case the blit would go onto the backing store,
> and this backing store would have to be copied to the screen manually.
> 
> But who does this copying?  It should be that after all 4 rectangles are
> drawn, the entire thing is copied to screen (or the gdk window is
> invalidated to trigger an expose event).  But since the caller may be in
> common code there's no hook for this operation.

> I think this corresponds to your FS case.  You're drawing to a backend
> buffer which is later flushed to the screen.  But who does the flushing?
>  The backend does it on request or when an expose event arrives: but
> without a hook into the overview draw function there's no way to request it.

I see your problem now. The answer is the function:

struct canvas_store {
  struct osda *osda;
  struct sw_widget *widget;
};

void gui_copy_canvas(struct canvas_store *dest, struct canvas_store *src,
                     int src_x, int src_y, int dest_x, int dest_y, int width,
                     int height)
{
  struct ct_size size = { width, height };
  struct ct_point src_pos = { src_x, src_y }, dest_pos = {
  dest_x, dest_y};

  be_copy_osda_to_osda(dest->osda, src->osda, &size, &dest_pos, &src_pos, 0);
  if (dest->widget) {
    sw_window_canvas_background_region_needs_repaint(dest->widget, NULL);
  }
}

The model is goes like this. To enable the injection of custom
graphics (read providing a canvas) the widget set provides the ability
to use the background of the window widget as a canvas.

You enable it with:

  void sw_window_set_canvas_background(struct sw_widget *widget, bool yes);

And you get the canvas osda to which you draw the whatever you want:

  struct osda *sw_window_get_canvas_background(struct sw_widget *widget);

You however have to inform the widget set that part of the canvas
background changed:

  void sw_window_canvas_background_region_needs_repaint(struct sw_widget
                                                      *widget,
                                                      const struct ct_rect
                                                      *region);

[ And yes this it the longest function name ;) the widget set uses. ]

The widget code will do all the remaining logic. Note that calling
sw_window_canvas_background_region_needs_repaint just queues this
dirty areas. It doesn't do any repaint right away.

You may guess now how the code for setting up the overview.window
looks like:

  overview.window->osda = sw_window_get_canvas_background(overview_window);
  overview.window->widget = overview_window;

So even with this very different model the initial abstraction of
"struct canvas_store" is implementable quite easy.

I think you could reimplement
sw_window_canvas_background_region_needs_repaint in gtk/gdk with an
self-send expose event if gtk/gdk doesn't have a function like this
anyway.

        Raimar

--
 email: rf13@xxxxxxxxxxxxxxxxx
 "Life is too short for reboots."