-
Notifications
You must be signed in to change notification settings - Fork 77
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
Switched to Queue based rendering #76
Conversation
Hah, nice way to handle it 👀 Glad someone else got it in! I do wonder what the impact of the fragment shader based discard might be, but maybe it's alright |
there should not be much impact since the GPU should optimize the rendering based on that. Though if we figured out a way to stream render glyphs which would mean to render an entire string in the shader versus inserting the string into a texture. we could still use the other method of clipping then. |
just updated this so it is now inline with master. Sadly had to do this the hard way since git did not want to auto merge =[. |
Make queue reference immutable in draw API
I have updated this which fixes the scissor and rendering issues that it originally had. it works without the staging belt! @hecrj |
@hecrj will this be merged anytime soon ? |
@VincentJousse probably not as he is looking into another renderer first to see if it will work better or not. But feel free to use it from my repo. |
So based on #69 I have updated this to use the latest version and have Temporarily fixed the Scissoring issue.
The issue seems to be the Command buffer if using staging belt would be copy draw copy draw while with queue would be copy copy copy draw draw draw. So Until you decide to change the way the system buffers the rendering into a single Draw call that holds onto index's in a uniform array or something else we will be forced to use Fragment Shader scissoring.
When switching to use queue over the staging belt we gain the benefit of being able to render with Tokio async on Main with winit Event loop.
Also the Clipper is not the Greatest as it is Actual Screen coords so the best way to improve upon this would probably be to calculate offsets into the Region before passing it onto the GPU.