Difference between revisions of "Ident TODO"

From CEGUI Wiki - Crazy Eddie's GUI System (Open Source)
Jump to: navigation, search
(SVG Tessellator tests)
 
(7 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 managers. 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.
+
* 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 tooltips to some demo ==
+
=== Add properties for the classes and maybe the entire output from the properties (such as done in the WidgetDemo) into the doxygen docs ===  
It is currently not covered anywhere. Or is it( need to check!)?
+
 
+
== 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 72: 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 109: Line 107:
  
 
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 =
 +
 +
=== Add tooltips to some demo ===
 +
<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 ;) )
 +
 +
=== 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

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

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