Difference between revisions of "Ident TODO"
(4 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
− | == CEGUI General == | + | === CEGUI General === |
* Texture filtering should use trilinear filtering, instead of bilinear for magnification in some (!) cases. Need to figure out which cases need which and implement a switch, etc | * Texture filtering should use trilinear filtering, instead of bilinear for magnification in some (!) cases. Need to figure out which cases need which and implement a switch, etc | ||
* <strike>Replacing ColourRect with Colour would allow us to strip all per-vertex attributes for colours and allows us to use a highly performant uniform instead. People who want fancy fonts etc should just use Bitmap Fonts and Widgets can simply be changed to using different Images instead of applying Gradients with ColourRect there as well. </strike> http://cegui.org.uk/forum/viewtopic.php?f=6&t=6863 | * <strike>Replacing ColourRect with Colour would allow us to strip all per-vertex attributes for colours and allows us to use a highly performant uniform instead. People who want fancy fonts etc should just use Bitmap Fonts and Widgets can simply be changed to using different Images instead of applying Gradients with ColourRect there as well. </strike> http://cegui.org.uk/forum/viewtopic.php?f=6&t=6863 | ||
Line 5: | Line 5: | ||
* Check for the necessity and performance loss of unproject calls : d_owner->getRenderTarget().unprojectPoint(*d_geometry, in, p_out); | * Check for the necessity and performance loss of unproject calls : d_owner->getRenderTarget().unprojectPoint(*d_geometry, in, p_out); | ||
* There are some Colour features that are currently unused and entirely undocumented in the CEGUI Colour class. I suggest replacing them with my own Colour classes, which were added along with the ColourPicker, and keeping onyl reworked and documented existing stuff. ( I think there was HSB or something?) | * There are some Colour features that are currently unused and entirely undocumented in the CEGUI Colour class. I suggest replacing them with my own Colour classes, which were added along with the ColourPicker, and keeping onyl reworked and documented existing stuff. ( I think there was HSB or something?) | ||
+ | * CEGUI default: rename isActive() to isInFocus() or similar to be more meaningful? http://cegui.org.uk/forum/viewtopic.php?f=10&t=7162 | ||
− | == Opengl Renderers == | + | === Opengl Renderers === |
* Improve OpenGL Renderer(s) extra states functions (and also rename it): | * Improve OpenGL Renderer(s) extra states functions (and also rename it): | ||
** Add and also do the restore for: glUseProgram(0); glBindVertexArray(0); glBindBuffer(GL_ARRAY_BUFFER, 0); glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,0); <br /> see https://github.com/kortemik/RBDOOM-3-BFG/blob/cegui/neo/sys/sdl/sdl_glimp.cpp#L553 | ** Add and also do the restore for: glUseProgram(0); glBindVertexArray(0); glBindBuffer(GL_ARRAY_BUFFER, 0); glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,0); <br /> see https://github.com/kortemik/RBDOOM-3-BFG/blob/cegui/neo/sys/sdl/sdl_glimp.cpp#L553 | ||
Line 13: | Line 14: | ||
** Good source: http://blogs.nvidia.com/blog/2014/03/20/opengl-gdc2014/ | ** Good source: http://blogs.nvidia.com/blog/2014/03/20/opengl-gdc2014/ | ||
− | == Renderers == | + | === Renderers === |
* If applying the ColourRect changes is successful and performance-wise alright<strike>, then it should be possible to use instancing for the vbo's, which basically allows to use a single VBO to render all windows. This whole procedure is supported by OpenGL 3.1+ Core (see: https://www.opengl.org/wiki/GLAPI/glDrawArraysInstanced ) and can therefore definitely be supported by the OGL3 Renderer. Probably D3D11 supports it as well (will have to look into it). </strike> After checking the instancing methods, I encountered that they are not really giving any advantage for low-complexity meshes. Still, there should be ways to reduce the amount of batches. | * If applying the ColourRect changes is successful and performance-wise alright<strike>, then it should be possible to use instancing for the vbo's, which basically allows to use a single VBO to render all windows. This whole procedure is supported by OpenGL 3.1+ Core (see: https://www.opengl.org/wiki/GLAPI/glDrawArraysInstanced ) and can therefore definitely be supported by the OGL3 Renderer. Probably D3D11 supports it as well (will have to look into it). </strike> After checking the instancing methods, I encountered that they are not really giving any advantage for low-complexity meshes. Still, there should be ways to reduce the amount of batches. | ||
− | == SVG == | + | === SVG === |
* Need to implement MSAA in all Renderers as alternative for the alpha blending AA | * Need to implement MSAA in all Renderers as alternative for the alpha blending AA | ||
* Need to fix D3D11 Rendering of SVG demo | * Need to fix D3D11 Rendering of SVG demo | ||
− | == SampleBrowser == | + | === SampleBrowser === |
− | * Separate duties (input, Renderer-related stuff, etc) in different | + | * Separate duties (input, Renderer-related stuff, etc) in different facades. Reduce the inheritation levels to a maximum of one. Simplify the classes. Make initialisation and deinitialisation more overlookable. Remove namespace "CEGUI" from all Sample-related stuff. |
− | == CEGUI docu == | + | === CEGUI docu === |
* Improve cegui docu: | * Improve cegui docu: | ||
<source lang="text"> | <source lang="text"> | ||
Line 58: | Line 59: | ||
</source> | </source> | ||
− | == SVG Tessellator tests == | + | === SVG Tessellator tests === |
Should be done for the various tessellator functions by comparing against the expected result in each case (as I did with the PropertyHelper unit tests) | Should be done for the various tessellator functions by comparing against the expected result in each case (as I did with the PropertyHelper unit tests) | ||
− | == Add properties for the classes and maybe the entire output from the properties (such as done in the WidgetDemo) into the doxygen docs == | + | === Add properties for the classes and maybe the entire output from the properties (such as done in the WidgetDemo) into the doxygen docs === |
<source lang="text"> | <source lang="text"> | ||
[18:52:13] BoomerBile if you /*** this is the comment for class X | [18:52:13] BoomerBile if you /*** this is the comment for class X | ||
Line 69: | Line 70: | ||
</source> | </source> | ||
− | == Adapt CEGUI System/Renderer for multi-window support and write a simple demo app == | + | === Adapt CEGUI System/Renderer for multi-window support and write a simple demo app === |
See: | See: | ||
https://bitbucket.org/cegui/cegui/pull-request/141/improved-ogre-renderer/diff#comment-5004142 | https://bitbucket.org/cegui/cegui/pull-request/141/improved-ogre-renderer/diff#comment-5004142 | ||
Line 107: | Line 108: | ||
http://www.glfw.org/docs/latest/group__context.html#ga15a5a1ee5b3c2ca6b15ca209a12efd14 | http://www.glfw.org/docs/latest/group__context.html#ga15a5a1ee5b3c2ca6b15ca209a12efd14 | ||
+ | === Image / Font autoscaling should be GUIContext-specific === | ||
+ | As brought up by Naros on #cegui, currently System has a notifyDisplaySizeChanged function, which makes no sense, as we have been supporting multiple concurrent GUIContexts at a time. The function propagates the notification to FontManager and ImageManager which use it for autoscaling. While it makes sense to share the image and font definitions, it doesnt make sense to share the final scale result between guicontexts. So these should be stored for each font and image separately per GUIContexts. To be specific, that would be the d_scaledSize and d_scaledOffset for each. The function itself should be removed. --> all of this has to go into default branch. A ticket has to be created for this yet on bitbucket. | ||
= FINISHED = | = FINISHED = | ||
− | == Add tooltips to some demo == | + | === Add tooltips to some demo === |
<strike>It is currently not covered anywhere. Or is it( need to check!)?</strike> | <strike>It is currently not covered anywhere. Or is it( need to check!)?</strike> | ||
Added to the look n' feel demo (and fixed some bugs with inherited tooltips that I noticed ;) ) | Added to the look n' feel demo (and fixed some bugs with inherited tooltips that I noticed ;) ) | ||
+ | |||
+ | === Glyph rendering and Freetype Font rework === | ||
+ | * Fixed: Glyph atlas creation algorithm completely overworked and simplified and made more efficient | ||
+ | * Fixed: Kerning and raqm support added | ||
+ | * Won't fix: Glyph atlas is RGBA despite being single-channel, but turning it to single channel requires shader changes and makes renderer support difficult... | ||
+ | * Won't fix: We don't support LCD subpixel rendering, as it depends too much on hardware and single channel is good enough | ||
+ | * Won't fix: Won't support subpixel positiong because small Font sizes can get blurrier than normal if moved to a subpixel position, unfortunately, and small Fonts are the main reason to do this.. |
Latest revision as of 22:01, 2 May 2017
Contents
- 1 CEGUI General
- 2 Opengl Renderers
- 3 Renderers
- 4 SVG
- 5 SampleBrowser
- 6 CEGUI docu
- 7 SVG Tessellator tests
- 8 Add properties for the classes and maybe the entire output from the properties (such as done in the WidgetDemo) into the doxygen docs
- 9 Adapt CEGUI System/Renderer for multi-window support and write a simple demo app
- 10 Image / Font autoscaling should be GUIContext-specific
- 11 FINISHED
CEGUI General
- Texture filtering should use trilinear filtering, instead of bilinear for magnification in some (!) cases. Need to figure out which cases need which and implement a switch, etc
-
Replacing ColourRect with Colour would allow us to strip all per-vertex attributes for colours and allows us to use a highly performant uniform instead. People who want fancy fonts etc should just use Bitmap Fonts and Widgets can simply be changed to using different Images instead of applying Gradients with ColourRect there as well.http://cegui.org.uk/forum/viewtopic.php?f=6&t=6863 - setAlpha apparently triggers recreation of GeometryBuffer should be replaced by a uniform instead of applying it to the per-vertex attributes (Done by Henri - Todo:Check if this is really 100% bullet-proof)
- Check for the necessity and performance loss of unproject calls : d_owner->getRenderTarget().unprojectPoint(*d_geometry, in, p_out);
- There are some Colour features that are currently unused and entirely undocumented in the CEGUI Colour class. I suggest replacing them with my own Colour classes, which were added along with the ColourPicker, and keeping onyl reworked and documented existing stuff. ( I think there was HSB or something?)
- CEGUI default: rename isActive() to isInFocus() or similar to be more meaningful? http://cegui.org.uk/forum/viewtopic.php?f=10&t=7162
Opengl Renderers
- Improve OpenGL Renderer(s) extra states functions (and also rename it):
- Add and also do the restore for: glUseProgram(0); glBindVertexArray(0); glBindBuffer(GL_ARRAY_BUFFER, 0); glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,0);
see https://github.com/kortemik/RBDOOM-3-BFG/blob/cegui/neo/sys/sdl/sdl_glimp.cpp#L553 - http://cegui.org.uk/forum/viewtopic.php?f=10&t=6752&sid=6bb9fb4a04417b28278538ed3f89af57&p=31632#p31632
- What about blending and scissor test?
- Good source: http://blogs.nvidia.com/blog/2014/03/20/opengl-gdc2014/
- Add and also do the restore for: glUseProgram(0); glBindVertexArray(0); glBindBuffer(GL_ARRAY_BUFFER, 0); glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,0);
Renderers
- If applying the ColourRect changes is successful and performance-wise alright
, then it should be possible to use instancing for the vbo's, which basically allows to use a single VBO to render all windows. This whole procedure is supported by OpenGL 3.1+ Core (see: https://www.opengl.org/wiki/GLAPI/glDrawArraysInstanced ) and can therefore definitely be supported by the OGL3 Renderer. Probably D3D11 supports it as well (will have to look into it).After checking the instancing methods, I encountered that they are not really giving any advantage for low-complexity meshes. Still, there should be ways to reduce the amount of batches.
SVG
- Need to implement MSAA in all Renderers as alternative for the alpha blending AA
- Need to fix D3D11 Rendering of SVG demo
SampleBrowser
- Separate duties (input, Renderer-related stuff, etc) in different facades. Reduce the inheritation levels to a maximum of one. Simplify the classes. Make initialisation and deinitialisation more overlookable. Remove namespace "CEGUI" from all Sample-related stuff.
CEGUI docu
- Improve cegui docu:
[17:07:59] Ident we really need to fix the docu for how to set up an application for CEGUI [17:08:33] Ident and by "we" i mean someone except me [17:12:50] timotei Ident: Well, there is already one, isn't it? :P [17:13:07] Ident it lacks crucial info [17:13:12] timotei Like? [17:13:19] Ident how to deinitialise cegui [17:13:25] Ident how to update cegui exactly (code samples) [17:13:37] Ident for example the notifydisplaysizechanged [17:13:49] Ident or how to render in detail [17:14:11] Ident there were some posts in the forum in that regard too [17:14:20] Ident when i have time i look through all of them and update the api docu [17:14:21] timotei CEGUI_SamplesBrowser provides some examples as far as I know [17:14:24] Ident nah [17:14:31] Ident thats not a good place to look for this [17:14:32] timotei Or you mean, simple CEGUI-ed application? [17:14:35] Ident the rendering is super-specific [17:14:43] Ident and also some of it is hidden [17:14:55] Ident it doesnt make sense to look into SamplesBrowser [17:15:13] Ident thats not what the browser is there for [17:17:35] Ident how to make an application using cegui should be well documented with examples in the api docu [17:17:43] Ident this should be the only resource for this [17:17:57] timotei I see :) [17:17:59] Ident then- how to initialise resources, load layouts and use cegui - this is where the samples come into play [17:18:00] Ident because [17:18:12] Ident there is many different ways to set up a cegui application [17:18:21] Ident we cant cover all [17:18:39] Ident of course we can and should provide code snippetsd http://cegui.org.uk/forum/viewtopic.php?f=10&t=6772&p=31775#p31775
SVG Tessellator tests
Should be done for the various tessellator functions by comparing against the expected result in each case (as I did with the PropertyHelper unit tests)
Add properties for the classes and maybe the entire output from the properties (such as done in the WidgetDemo) into the doxygen docs
[18:52:13] BoomerBile if you /*** this is the comment for class X [18:52:44] BoomerBile *** m_SomeVariable description [18:53:01] BoomerBile *** @property description [18:53:09] BoomerBile it will dump them into the api docs
Adapt CEGUI System/Renderer for multi-window support and write a simple demo app
See: https://bitbucket.org/cegui/cegui/pull-request/141/improved-ogre-renderer/diff#comment-5004142
and:
[15:20:53] Ident so how do you render to another window? [15:21:23] Ident if you just need to swap the FBO to render to another platofrm window then it should be easily doable in cegui [15:22:32] Luben to render to another window i would keep the default(0) fbo bound but switch ogl context if i remember correctly [15:23:04] Ident in that case the solution is also simple [15:23:12] Ident do u still have that function i gave u before open? [15:23:28] Luben SampleData::initialize? [15:24:52] Ident in the heavily convoluted System::System() constructor [15:24:54] Ident you will find [15:25:02] Ident this line: createGUIContext(d_renderer->getDefaultRenderTarget()); [15:25:14] Ident what does this mean? it creates a guicontext with the default rendertarget [15:25:36] Ident the defaultrendertarget is basically [15:25:37] Ident FBO 0 [15:25:44] Ident so what you would wanna do is create 3 of these [15:25:52] Ident or X of these for X amount of windows [15:26:11] Ident and when you draw them, you change your OpenGL Context before each draw call [15:30:20] Ident also do u know how to draw? [15:31:09] Luben i checked renderAllGUIContexts so i think i should be ok [15:31:14] Ident good good [15:31:25] Ident createGUIContext(d_renderer->getDefaultRenderTarget()); is all you need [15:31:28] Ident u dont need to specify a size [15:31:37] Ident oh wait [15:31:39] Ident yea [15:31:43] Ident this means that it will only work [15:31:47] Ident if all your windows are the same size [15:31:56] Ident the size that is specified for system::notifydisplaysizechanged [15:32:14] Luben well, that blows..
docs: http://blog.gvnott.com/2013/05/18/tutorial-multiple-windows-with-glfw3-and-glew-mx/
http://www.glfw.org/docs/latest/group__context.html#ga15a5a1ee5b3c2ca6b15ca209a12efd14
Image / Font autoscaling should be GUIContext-specific
As brought up by Naros on #cegui, currently System has a notifyDisplaySizeChanged function, which makes no sense, as we have been supporting multiple concurrent GUIContexts at a time. The function propagates the notification to FontManager and ImageManager which use it for autoscaling. While it makes sense to share the image and font definitions, it doesnt make sense to share the final scale result between guicontexts. So these should be stored for each font and image separately per GUIContexts. To be specific, that would be the d_scaledSize and d_scaledOffset for each. The function itself should be removed. --> all of this has to go into default branch. A ticket has to be created for this yet on bitbucket.
FINISHED
Add tooltips to some demo
It is currently not covered anywhere. Or is it( need to check!)?
Added to the look n' feel demo (and fixed some bugs with inherited tooltips that I noticed ;) )
Glyph rendering and Freetype Font rework
- Fixed: Glyph atlas creation algorithm completely overworked and simplified and made more efficient
- Fixed: Kerning and raqm support added
- Won't fix: Glyph atlas is RGBA despite being single-channel, but turning it to single channel requires shader changes and makes renderer support difficult...
- Won't fix: We don't support LCD subpixel rendering, as it depends too much on hardware and single channel is good enough
- Won't fix: Won't support subpixel positiong because small Font sizes can get blurrier than normal if moved to a subpixel position, unfortunately, and small Fonts are the main reason to do this..