some thoughts on surfaces and draw callbacks

[arvidn]

It seems to me that surface interface is quite fat. In fact, the oddest responsibility of surfaces in my mind is calling the draw callback at specified intervals and times.

some draw_callback() functions take a callback that's passed a basic_output_surface& (without the template argument specified) but basic_unmanaged_output_surface has a draw_callback() that instead takes a basic_unordered_output_surface (still no template parameter specified).

My understanding (maybe mostly assumptions) is that the reason to draw from within a callback is so that the library can first set up things like clip-regions to match only the area that needs redrawing, and also to give the library a way to request redrawing in the event of windows being covered (and then uncovered) by other windows, as well as having windows resized.

Can the draw calls on a surface be made outside of a callback as well?

I would imagine one way to simplify surfaces, and I would argue also make the interface simpler, would be to separate the responsibility to notify a program that some part of a surface need to be redrawn, and the actual drawing itself.

One way to implement temporary clip regions while updating would be to have something similar to a lock_guard, but maybe a clip_region_guard<Surface>. There are already other (and I would argue better) mechanisms of being notified of events on their way into the standard. like the executors and networking proposals.

[mikebmcl]

Draw calls cannot be made outside of the callback. I think of the callback as something that will, I believe, enable batching of calls for hardware accelerated implementations. We might need to make further changes to make this practical and users will need to write code in a way that makes it possible. For example, any change that results in the need to modify the contents of any basic_interpreted_path will degrade performance since it will need to be regenerated from its source input. Swapping one existing basic_interpreted_path for another would not be a performance issue though since it's just a change to a shader input, not a creation of a new resource.

The clip region definitely comes in to play, but unless it's modified in a way that requires it to be regenerated, it's simply a shader input with no cost penalty (even if another existing clip region is swapped in).

Changes to anything else should not be disruptive and might not result in any significant performance hits since they would be changes to shader inputs and state objects, and those mostly don't take much time to perform. That's the desired result, anyway.

Executors are definitely something we will consider when they are formally part of the standard. There are differences in specifications of them and those issues are still being worked out. So we will be sticking with callbacks for now but will certainly consider new features in standard C++ that improve the API. As an example, what are now called figure_item objects switched to using variant once C++17 was published.

We are aiming for a TS (i.e. a separate publication that would go into the Standard itself). It might take several TSs to get 2D graphics to a point where it is acceptable to the C++ committee for inclusion in the Standard. (It might ultimately fail to meet the criteria for inclusion in the Standard and thus either be shipped as a separate standard in some form or dropped entirely, but we don't feel that this will be the result, notwithstanding the result of the evening session poll in Rapperswil).

The goal of all TSs is to get implementations of them that are widely available and then to drum up support that gets C++ programmers to use them in order to get feedback about the APIs, especially constructive criticism, so that issues are identified, resolved, and, if necessary, published in another TS to see if the changes meet the needs of C++ programmers who will use these APIs in real world code.