Performance Tips - Revision history

Bablakeluke: Redirected page to Performance

2017-05-01T18:13:34Z

Redirected page to Performance

151.229.186.156: /* Precompile PowerUI */

2017-02-16T04:39:26Z

‎Precompile PowerUI

151.229.186.156: /* Precompile PowerUI */

2017-02-11T22:46:14Z

‎Precompile PowerUI

151.229.186.156: /* Precompile PowerUI */

2017-02-11T18:32:18Z

‎Precompile PowerUI

151.229.186.156 at 18:30, 11 February 2017

2017-02-11T18:30:12Z

151.229.186.156: Created page with "PowerUI is naturally fast, but there's always a few things you can do to make your UI's go ever faster! == Boosting Reflow == Reflow is the process that a web user agent goe..."

2017-02-11T18:15:04Z

Created page with "PowerUI is naturally fast, but there's always a few things you can do to make your UI's go ever faster! == Boosting Reflow == Reflow is the process that a web user agent goe..."

New page

PowerUI is naturally fast, but there's always a few things you can do to make your UI's go ever faster!

== Boosting Reflow ==

Reflow is the process that a web user agent goes through to figure out the position of elements on the screen. It's the most expensive thing PowerUI (or any user agent) does so avoiding triggering it will give you some nice savings.

=== Use paint properties ===

A range of properties like '''opacity, color, transform''' only trigger a ''paint'' because they are post processes. Paints are extremely fast.

=== Limiting reflow scope ===

Reflow applies to the nearest ''flow root'' element. For example, let's say you update the innerHTML of a fixed/absolute/sticky '''positioned element''' then ''only that element will actually reflow''. The same applies to any of the nested kids of that positioned element - it'll bubble up the DOM to the nearest flow root, and request to reflow that element. In short, making an element become a ''flow root'' is an easy way to massively limit how many elements reflow actually affects.

== Set textContent rather than innerHTML ==

If you know your text contains no HTML then setting to textContent will cause virtually everything to get recycled. Setting innerHTML is fast anyway but textContent does almost nothing.

== Disabling Unicode Bidirectionality ==

If you have no plans to use right-to-left or bidirectional text (like Arabic mixed with English), disable it by deleting '''PowerUI/Resources/BidirectionalData.bytes'''. This will give you a small memory saving (about 10kb) and slightly boost text performance.

You can also go further by specifying '''NoBIDI''' as a "scripting define symbols" as that will effectively remove all of the code which does the BIDI testing.

== Avoid late loading CSS ==

This is a massive performance drainer - avoid it! Put style as high up your document as you can (e.g. in head). That's because a newly loaded CSS selector must ''check your entire DOM'' to see if they match any of the elements already in there. If your DOM is basically empty then this operation is much faster.

Meanwhile, a newly loading element uses a range of indices to very rapidly figure out which selectors actually apply to it.

← Older revision		Revision as of 18:13, 1 May 2017
Line 1:		Line 1:
−	~~PowerUI is naturally fast, but there's always a few things you can do to make your UI's go ever faster!~~	+	#REDIRECT [[Performance]]
−
−	~~== Precompile PowerUI ==~~
−
−	~~Performance applies to your development process too. Unless you've got a solid state hard drive, PowerUI can take some 15 seconds to compile. Every time you change any of your C~~# ~~files.~~ [[~~Precompiler\|Precompile PowerUI~~]] ~~by going to '''Window > PowerUI > Precompile''' then just tick the box - that will entirely eliminate this delay for you.~~
−
−	~~'''If you change platform, or update Unity, you must precompile it again!''' That's because things like UNITY_ANDROID matter a lot.~~
−
−	~~Note that precompiling does not affect custom tags etc, but it does affect any ''partial class extensions''.~~
−
−	~~== Boosting Reflow ==~~
−
−	Reflow is the process that a web user agent goes through to figure out the position of elements on the screen. It's the most expensive thing PowerUI (or any user agent) does so avoiding triggering it will give you some nice savings.
−
−	~~=== Use paint properties ===~~
−
−	~~A range of properties like '''opacity, color, transform''' only trigger a ''paint'' because they are post processes. Paints are extremely fast.~~
−
−	~~=== Limiting reflow scope ===~~
−
−	Reflow applies to the nearest ''flow root'' element. For example, let's say you update the innerHTML of a fixed/absolute/sticky '''positioned element''' then ''only that element will actually reflow''. The same applies to any of the nested kids of that positioned element - it'll bubble up the DOM to the nearest flow root, and request to reflow that element. In short, making an element become a ''flow root'' is an easy way to massively limit how many elements reflow actually affects.
−
−	~~== Set textContent rather than innerHTML ==~~
−
−	~~If you know your text contains no HTML then setting to textContent will cause virtually everything to get recycled. Setting innerHTML is fast anyway but textContent does almost nothing.~~
−
−	~~== Disabling Unicode Bidirectionality ==~~
−
−	If you have no plans to use right-to-left or bidirectional text (like Arabic mixed with English), disable it by deleting '''PowerUI/Resources/BidirectionalData.bytes'''. This will give you a small memory saving (about 10kb) and slightly boost text performance.
−
−	~~You can also go further by specifying '''NoBIDI''' as a "scripting define symbols" as that will effectively remove all of the code which does the BIDI testing.~~
−
−	~~== Avoid late loading CSS ==~~
−
−	This is a massive performance drainer - avoid it! Put style as high up your document as you can (e.g. in head). That's because a newly loaded CSS selector must ''check your entire DOM'' to see if they match any of the elements already in there. If your DOM is basically empty then this operation is much faster.
−
−	~~Meanwhile, a newly loading element uses a range of indices to very rapidly figure out which selectors actually apply to it.~~

@@ Line 3: / Line 3: @@
 == Precompile PowerUI ==
-Performance applies to your development process too. Unless you've got a solid state hard drive, PowerUI can take some 15 seconds to compile. Every time you change any of your C# files. Precompile PowerUI by going to '''Window > PowerUI > Precompile''' then just tick the box - that will entirely eliminate this delay for you.
+Performance applies to your development process too. Unless you've got a solid state hard drive, PowerUI can take some 15 seconds to compile. Every time you change any of your C# files. [[Precompiler|Precompile PowerUI]] by going to '''Window > PowerUI > Precompile''' then just tick the box - that will entirely eliminate this delay for you.
 '''If you change platform, or update Unity, you must precompile it again!''' That's because things like UNITY_ANDROID matter a lot.

@@ Line 7: / Line 7: @@
 '''If you change platform, or update Unity, you must precompile it again!''' That's because things like UNITY_ANDROID matter a lot.
-By default, PowerUI only checks the assembly that its own classes are in for tags. If you use custom tags/ properties etc, they should be precompiled with it by putting them in any sub-directory of PowerUI. Alternatively, you can request PowerUI to scan additional assemblies for tags/ properties etc; that's the UI.SearchAssembly method (and you'd do it once during startup).
+Note that precompiling does not affect custom tags etc, but it does affect any ''partial class extensions''.
 == Boosting Reflow ==

@@ Line 7: / Line 7: @@
 '''If you change platform, or update Unity, you must precompile it again!''' That's because things like UNITY_ANDROID matter a lot.
-By default, PowerUI only checks the assembly that its own classes are in for tags. If you use custom tags/ properties etc, they should be precompiled with it by putting them in any sub-directory of PowerUI. Alternatively, you can request PowerUI to scan additional assemblies for tags/ properties etc; that's the UI.ScanDll method (and you'd do it once during startup).
+By default, PowerUI only checks the assembly that its own classes are in for tags. If you use custom tags/ properties etc, they should be precompiled with it by putting them in any sub-directory of PowerUI. Alternatively, you can request PowerUI to scan additional assemblies for tags/ properties etc; that's the UI.SearchAssembly method (and you'd do it once during startup).
 == Boosting Reflow ==

← Older revision		Revision as of 18:30, 11 February 2017
Line 1:		Line 1:
	PowerUI is naturally fast, but there's always a few things you can do to make your UI's go ever faster!		PowerUI is naturally fast, but there's always a few things you can do to make your UI's go ever faster!
		+
		+	== Precompile PowerUI ==
		+
		+	Performance applies to your development process too. Unless you've got a solid state hard drive, PowerUI can take some 15 seconds to compile. Every time you change any of your C# files. Precompile PowerUI by going to '''Window > PowerUI > Precompile''' then just tick the box - that will entirely eliminate this delay for you.
		+
		+	'''If you change platform, or update Unity, you must precompile it again!''' That's because things like UNITY_ANDROID matter a lot.
		+
		+	By default, PowerUI only checks the assembly that its own classes are in for tags. If you use custom tags/ properties etc, they should be precompiled with it by putting them in any sub-directory of PowerUI. Alternatively, you can request PowerUI to scan additional assemblies for tags/ properties etc; that's the UI.ScanDll method (and you'd do it once during startup).

	== Boosting Reflow ==		== Boosting Reflow ==