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