Re: [Boost-users] [rfc] GIL, draw operations, GUI [and maybe AGG?]

From: John Femiani (JOHN.FEMIANI_at_[hidden])
Date: 2008-07-10 15:14:41

Felipe wrote:

> > I think you will need to be able to associate some kind of context 
> > with the surface right? A current coordinate-transform for instance.
> 
> I think we could do something like this:
> 
> using namespace surfaces;
> using namespace gui;
> using namespace gil;
> 
> no_anti_aliasing_surface<rgb8_view_t>
> image_surface(interleaved_view(w, h, pointer_to_raw));
> 
> wnd<> w = create<>( _title = "Titulo" );

I would not make wnd<> part of the lib.

> 
> surface_create_line(*w, w->origin(), w->origin() + 
> gui::make_point(10, 10));
> 
> I guess a coordinate-transform would only be used when 
> projecting a surface on another right?
> When for example drawing an image.
> 

Whenever a point is drawn. I think OpenGL gives a good example; The
surface should probably keep a transform operation and internally
multiply each point by it. Have you researched any other API's to see
how they do it? I just know OpenGL, Java2D, and windows Device Contexts.

> struct my_coordinate_transform
> {
>   gui::point operator()(surface::pixel_point<std::size_t> 
> pos) const; };
> 
> surface_project(*w, image_surface, my_coordinate_transform());
> 
> What do you think?
> 

That's right, but especially the linear or projective transforms formed
by 2x2, 3x3, or 4x4 matrices need to be handled, since they are most
common for affine transforms and they usually have some hardware
support.

I am thinking:

   image_surface canvas(m_device, my_image);
   canvas.push_transform(rotates(3));
   ...
   ASSERT(!canvas.locked());
   image_surface::buffer_image buf(canvas, 0, 0, w, h); 
   ASSERT(canvas.locked());

This way the canvas can provide drawing operations, and also a
buffer_image type. 
The canvas should be 'locked' during the lifetime of the buffer_image,
becase most of 
The drawing and even display operations can happen inside the video
card, and the pixels
Have to be copied in and out before you can access them via GIL.

Here is another approach: You could just try a simple scene graph:

   scene_graph g;
   rot3 = g.push(rotate(3*degrees()))
   line = rot3.push(line(0,0, 100, 100))
   box  = rot3.push(rectangle(10, 10, 20, 10))
    
   rgb8_image_t img;
   g.flatten(view(img);

I actually think the second approach is more flexible.