-
Notifications
You must be signed in to change notification settings - Fork 163
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unified rasterization API proposal #680
Comments
I like your proposal very much. Both, interfaces and implementation. Such unification via an extra level of indirection does not change the existing, let's say, low level interface, yet offers a clean and friendly one. |
At the start I thought about providing some sort of fancy iterator that would avoid creating temporary vector. Now with the advent of coroutines I believe it would be great to just create a coroutine that would yield coordinates, then build an easy to use frontend that would support the basic use cases. |
Yes, I also thought that lazy-evaluated coroutines could eliminate the need for extra memory allocation. This proposal here could serve as a stable API across different kind of rasterizers and the implementation could easily be changed in C++20 without having to change the interface. |
I think there is nothing wrong with hosting conditionally-compiled implementation based on coroutines enabled for C++20 compilation. |
This PR implements the gil::apply_rasterizer() free function mentioned in #680.
I will close the issue as it is merged. And regarding coroutines: If P2502 makes it into C++23 (looks promising), my personal preference would be to delay implementation of generators until then rather than reinventing the wheel. |
Yes, thanks. I'm so used to issues being closed via commits and I tend to forget to check they have been closed indeed 😊 I agree with your plan. |
Description
Three different kind of rasterizers have been implemented during GSoC 2020 and GSoC 2021: line, circle and ellipse rasterizers. These implementations are currently staged as extensions for releasing with Boost 1.80. While they all serve a similar purpose, their API is considerable different. Some of my concerns I have already summerized in another comment.
Suppose we want to draw a red circle or ellipse onto a black background image using the current API:
Circle:
Ellipse:
The circle API only supports generating the curve via an output iterator and puts the burden of applying the pixels to the image on the client-side. The ellipse API applies the pixels via implemented call operator to the image. Both solutions do not fit very well in the overall Boost.Gil API design in my opinion.
Proposed solution
One possible solution to unify the API of all currently implemented rasterizers and possible future implementations could be to separate the drawing aspect into a free function:
Circle:
Ellipse:
Possible implementation
The free function approach could be implemented via tag-dispatch to a detail functor:
apply_rasterizer.hpp:
circle_rasterizer.hpp:
The text was updated successfully, but these errors were encountered: