Performance tips - Revision history

Mmixlinus: /* Small tiled images */

2013-11-25T22:00:21Z

‎Small tiled images

Mmixlinus: /* Imagesets & Texture atlases */

2013-11-25T21:59:18Z

‎Imagesets & Texture atlases

Capek: Robot: Cosmetic changes

2011-03-13T13:33:45Z

Robot: Cosmetic changes

Kulik at 10:57, 9 March 2011

2011-03-09T10:57:59Z

Kulik: /* Small tiled images */

2011-03-09T10:49:53Z

‎Small tiled images

Kulik: /* Imagesets & Texture atlases */

2011-03-09T10:48:58Z

‎Imagesets & Texture atlases

Kulik at 10:47, 9 March 2011

2011-03-09T10:47:11Z

Kulik at 01:24, 1 March 2011

2011-03-01T01:24:08Z

Kulik: sorted stuff by frequence of appearance

2011-03-01T01:22:47Z

sorted stuff by frequence of appearance

Kulik at 01:21, 1 March 2011

2011-03-01T01:21:32Z

@@ Line 7: / Line 7: @@
 == Small tiled images ==
-A very common mistake. If you have a very small (lets say 1px * 1px image) in your imageset and you set your looknfeel to tile that image over 100 px, CEGUI has to generate a lot of triangles to fulfil your wishes! This will lead into very bad performance and should be avoided. Tiling is fine but keep it under control!
+A very common mistake. If you have a very small (lets say 1px * 1px image) in your imageset and you set your looknfeel to tile that image over 100 px, CEGUI has to generate a lot of triangles to fulfil your wishes! This will lead to very bad performance and should be avoided. Tiling is fine but keep it under control!
 (Note: Stretching doesn't have the same caveat, you can stretch 1px image over as many pixels as you want with just 2 triangles and one batch.)

@@ Line 12: / Line 12: @@
 == [[Imageset]]s & Texture atlases ==
-Texture switching is a very expensive operation, which is why CEGUI uses [[Imageset|imagesets]]. [[Imageset]]s allows you to put more images on one texture ([[imageset]] ~= texture atlas), thus (potentially) lowering the amount of texture switches when rendering. If you however are from the "[[Imageset]]s suck, it sucks that CEGUI uses them!" and use one bitmap file and one [[imageset]] per image, you might expect very poor performance (many many texture switches even when rendering a single widgets - all corners are in separate file, also batching is simply not possible since you need a separate texture per every rectangle, so one widget might end up being 20 batches or even more!).
+Texture switching is a very expensive operation, which is why CEGUI uses [[Imageset|imagesets]]. [[Imageset]]s allows you to put several images in one texture ([[imageset]] ~= texture atlas), thus (potentially) lowering the amount of texture switches when rendering. If you however are from the "[[Imageset]]s suck, it sucks that CEGUI uses them!" and use one bitmap file and one [[imageset]] per image, you might expect very poor performance (many many texture switches even when rendering a single widgets - all corners are in separate file, also batching is simply not possible since you need a separate texture per every rectangle, so one widget might end up being 20 batches or even more!).
-Bottom line is: Use [[Imageset|imagesets]], don't hate on them! And if you hate on them and use separate files, stop whining that CEGUI is slow and sucks :-D
+The bottom line is: Use [[Imageset|imagesets]], don't hate them! And if you still hate them and use separate files, stop whining that CEGUI is slow and sucks :-D
 (Note: CEGUI 0.8 will completely change the way imagesets work. We will have images, these will simply have a reference to texture file and UV coords of the rectangle we should use in the texture file, .imageset files will still load though, so all of this still applies, furthermore the new [[CEED]] editor will support automatic imageset/atlas creation from multiple files to lessen the imageset maintenance pain)

@@ Line 11: / Line 11: @@
 (Note: Stretching doesn't have the same caveat, you can stretch 1px image over as many pixels as you want with just 2 triangles and one batch.)
-== [[Imageset|Imagesets]] & Texture atlases ==
+== [[Imageset]]s & Texture atlases ==
-Texture switching is a very expensive operation, which is why CEGUI uses [[Imageset|imagesets]]. [[Imageset|Imagesets]] allows you to put more images on one texture ([[Imageset|imageset]] ~= texture atlas), thus (potentially) lowering the amount of texture switches when rendering. If you however are from the "[[Imageset|Imagesets]] suck, it sucks that CEGUI uses them!" and use one bitmap file and one [[Imageset|imageset]] per image, you might expect very poor performance (many many texture switches even when rendering a single widgets - all corners are in separate file, also batching is simply not possible since you need a separate texture per every rectangle, so one widget might end up being 20 batches or even more!).
+Texture switching is a very expensive operation, which is why CEGUI uses [[Imageset|imagesets]]. [[Imageset]]s allows you to put more images on one texture ([[imageset]] ~= texture atlas), thus (potentially) lowering the amount of texture switches when rendering. If you however are from the "[[Imageset]]s suck, it sucks that CEGUI uses them!" and use one bitmap file and one [[imageset]] per image, you might expect very poor performance (many many texture switches even when rendering a single widgets - all corners are in separate file, also batching is simply not possible since you need a separate texture per every rectangle, so one widget might end up being 20 batches or even more!).
 Bottom line is: Use [[Imageset|imagesets]], don't hate on them! And if you hate on them and use separate files, stop whining that CEGUI is slow and sucks :-D

@@ Line 11: / Line 11: @@
 (Note: Stretching doesn't have the same caveat, you can stretch 1px image over as many pixels as you want with just 2 triangles and one batch.)
-== Imagesets & Texture atlases ==
+== [[Imageset|Imagesets]] & Texture atlases ==
-Texture switching is a very expensive operation, which is why CEGUI uses imagesets. Imagesets allows you to put more images on one texture (imageset ~= texture atlas), thus (potentially) lowering the amount of texture switches when rendering. If you however are from the "Imagesets suck, it sucks that CEGUI uses them!" and use one bitmap file and one imageset per image, you might expect very poor performance (many many texture switches even when rendering a single widgets - all corners are in separate file, also batching is simply not possible since you need a separate texture per every rectangle, so one widget might end up being 20 batches or even more!).
+Texture switching is a very expensive operation, which is why CEGUI uses [[Imageset|imagesets]]. [[Imageset|Imagesets]] allows you to put more images on one texture ([[Imageset|imageset]] ~= texture atlas), thus (potentially) lowering the amount of texture switches when rendering. If you however are from the "[[Imageset|Imagesets]] suck, it sucks that CEGUI uses them!" and use one bitmap file and one [[Imageset|imageset]] per image, you might expect very poor performance (many many texture switches even when rendering a single widgets - all corners are in separate file, also batching is simply not possible since you need a separate texture per every rectangle, so one widget might end up being 20 batches or even more!).
-Bottom line is: Use imagesets, don't hate on them! And if you hate on them and use separate files, stop whining that CEGUI is slow and sucks :-D
+Bottom line is: Use [[Imageset|imagesets]], don't hate on them! And if you hate on them and use separate files, stop whining that CEGUI is slow and sucks :-D
 (Note: CEGUI 0.8 will completely change the way imagesets work. We will have images, these will simply have a reference to texture file and UV coords of the rectangle we should use in the texture file, .imageset files will still load though, so all of this still applies, furthermore the new [[CEED]] editor will support automatic imageset/atlas creation from multiple files to lessen the imageset maintenance pain)

@@ Line 8: / Line 8: @@
 == Small tiled images ==
 A very common mistake. If you have a very small (lets say 1px * 1px image) in your imageset and you set your looknfeel to tile that image over 100 px, CEGUI has to generate a lot of triangles to fulfil your wishes! This will lead into very bad performance and should be avoided. Tiling is fine but keep it under control!
 == Imagesets & Texture atlases ==

← Older revision		Revision as of 01:24, 1 March 2011
Line 24:		Line 24:
	== A quick and (relatively) painless way to get roughly 40% performance increase in certain areas (0.8 only!) ==		== A quick and (relatively) painless way to get roughly 40% performance increase in certain areas (0.8 only!) ==
	By default, CEGUI uses no custom allocators at all. That means the plain old new and delete. You can set the allocator to anything you want but we recommend nedmalloc. It's a very robust memory allocator tailored to give maximum performance. It speeds things up especially when initialising, loading layouts, creating windows, ... Give it a try. See [[Memory Allocation]] for more details.		By default, CEGUI uses no custom allocators at all. That means the plain old new and delete. You can set the allocator to anything you want but we recommend nedmalloc. It's a very robust memory allocator tailored to give maximum performance. It speeds things up especially when initialising, loading layouts, creating windows, ... Give it a try. See [[Memory Allocation]] for more details.
		+
		+	[[Category:Manuals]]
		+	[[Category:WIP]]

@@ Line 16: / Line 16: @@
 If you need multiple instances of the dialog, you need to clone the widget tree somehow. This is why Widget (Window in 0.7 and previous) ::clone method has been implemented (only CEGUI 0.7.5 and newer!). It allows you to clone the entire widget hiearchy. The idea is to load this when the dialog is first used (or even when loading the application, depends on how the dialog is used). Store the widget pointer somewhere (could be a static member variable in the Dialog class) and upon construction, just clone the hierarchy and add the cloned widget while leaving the original alone for further cloning.
 (TODO: add some example code)
 == Speeding up a rarely changing info window (or any widget) with complex elements inside it ==
@@ Line 24: / Line 21: @@
 Caveat: The texture caching causes the widget to hard clip its children to its dimensions! That means that a combobox at the bottom of a frame window will get "cut" when you open the options of it. This is likely to get fixed but as of now (5th January 2011) it's still a problem in both 0.7 and 0.8.

← Older revision		Revision as of 01:21, 1 March 2011
Line 2:		Line 2:

	This page provides some generic tips on getting the most performance out of CEGUI. People often claim that CEGUI is slow and don't realise it could be them doing something wrong. I will try to gather some areas where people claim CEGUI is slow and "just sucks" and try to provide tips about what is wrong.		This page provides some generic tips on getting the most performance out of CEGUI. People often claim that CEGUI is slow and don't realise it could be them doing something wrong. I will try to gather some areas where people claim CEGUI is slow and "just sucks" and try to provide tips about what is wrong.
		+
		+	== Debug vs Release mode ==
		+	The performance difference between Debug and Release (optimisations enabled) CEGUI can be quite dramatic. Ensure you run everything in release mode when judging performance.
		+
		+	== Small tiled images ==
		+	A very common mistake. If you have a very small (lets say 1px * 1px image) in your imageset and you set your looknfeel to tile that image over 100 px, CEGUI has to generate a lot of triangles to fulfil your wishes! This will lead into very bad performance and should be avoided. Tiling is fine but keep it under control!

	== Problem: Loading layouts takes few seconds and halts my application! ==		== Problem: Loading layouts takes few seconds and halts my application! ==