search

priyankparekh / gdipp

Automatically exported from code.google.com/p/gdipp
0 stars 0 forks source link

gdipp with GetGlyphOutline is much slower than ClearType #207

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
According to the project summary page gdipp has “ignorable overhead”. 
However in my usage case I found that this is far from true.

The scrolling of news.google.com is slow in Google Chrome and Firefox. The 
scrolling in services.msc (when maximized on 1920x1080 display) is also slow. 
Windows Task Manager shows ~90% usage for itself (taskmgr.exe), when it is 
configured to sort processes by CPU usage (in 646x954 pixels window). Because 
by default it runs with High priority it effectively throttles almost every 
other process in the system while it is running. By comparison the CPU usage of 
taskmgr.exe in the same setting with ClearType rendering instead of gdipp (with 
GetGlyphOutline) is ~16%.

I tried to measure the text rendering speed with gdipp_demo_32.exe and 
gdipp_pre_32.exe, but both of them gave me an error message: “R6030 – CRT 
not initialized” (I’m using LCD display. I performed repair installation of 
gdipp, but this didn’t solve the problem). 

I’m using a machine with 32 bit 2.2 Ghz single core Intel processor. The OS 
is Windows Server 2008 SP2. The installation type of gdipp v0.7.6 is Registry.

Original issue reported on code.google.com by mays...@hotmail.com on 19 Jan 2012 at 8:49

GoogleCodeExporter commented 8 years ago 
Have you tried using the latest version (0.9.1)?

Also, what graphics adaptor are you using?

Original comment by jmbat...@gmail.com on 20 Jan 2012 at 2:01

GoogleCodeExporter commented 8 years ago 
If I remember correctly, in early versions (e.g. 0.7.6), gdipp does not have 
extensive cache system. While FreeType itself has internal caching mechanism, 
glyphs and glyph runs rendered in GGO mode are not cached. Therefore every time 
new glyphs are rendered anew.

The lack of caching may produce noticeable overhead in low-end computers. I did 
not experiment on 2.2 GHz single core Intel processor. I would expect 5%-10% 
extra overhead on GGO over FT renderer from gdipp_demo. Overhead between GGO 
and native ClearType could be even higher, but usually both of them are good 
enough to be noticeable. That's why I wrote "ignorable". Also, Windows Server 
2008 may have different scheduling policies, different kernel priority for 
graphics tasks (gdipp use GDI APIs extensively), different other aspects than 
desktop OS.

My suggestion is try and compare gdipp 0.9.1. If possible, try on Windows 7 and 
compare. Your feedback will be valuable to all users.

Original comment by crendk...@gmail.com on 20 Jan 2012 at 2:24

GoogleCodeExporter commented 8 years ago 
I installed gdipp v0.9.1. Then I set <renderer>20</renderer> in 
gdipp_setting.xml and restarted the gdipp Service. Now the CPU usage of 
taskmgr.exe is between 30%-37%. gdipp_demo_32.exe now works and gives the 
following results from three runs (top window/bottom window ms per text run): 
6.14/5.97, 5.99/5.82, 5.59/5.98.

With renderer set to 10, I got similar CPU usage of taskmgr.exe. From three 
runs of gdipp_demo_32.exe I obtained: 5.04/5.24, 5.36/5.15, 5.47/5.53.

With stopped gdipp Service I got 13-16% CPU usage of taskmgr.exe. 
gdipp_demo_32.exe reported: 4.93/5.16, 5.05/5.18, 5.27/4.99.

These results are from Windows Server 2008 SP2, whose processor scheduling 
setting is set to “Programs” (from sysdm.cpl -> Advanced -> Performance 
Settings… -> Advanced). The video card has ATI (AMD) chipset, supports 
DirectX 10.1 and works fine with Windows Aero.

I tried to install gdipp v0.9.1 on Windows 2003 SP2 but the installation failed 
with two error messages (gdipp 1.png and gdipp 2.png). The letter of the system 
partition of this Windows is not C. I tried “subst c: <system drive>:\”, 
but this didn’t solve the problem.

I can try to install gdipp on a machine with Windows 7, but this system has 
different hardware (64 bit 2 cores CPU). So even if I perform the same text 
render measurements they won’t be directly comparable with the above ones. 
Aside from this I’m not interested to use gdipp in desktop OS and I don’t 
see a clear reason to think that the type of OS matters for the performance of 
gdipp.

> Your feedback will be valuable to all users.

That’s a way to say indirectly “work for my project for free”.

Original comment by mays...@hotmail.com on 21 Jan 2012 at 6:26

Attachments:

GoogleCodeExporter commented 8 years ago 
I found a solution for the installation problem (the error message "The system 
cannot open the device or file specified.") with the aid of Process Monitor. 
This problem affects programs which use the MSI installer. When a user attempts 
to install a msi file, the system spawns an installer process that runs under 
the SYSTEM account. This process tries to open the msi file and if the later 
lacks permissions for the SYSTEM account the installation will fail with this 
error message.

So a local solution to this problem is to grant the SYSTEM account full access 
(“Full control”) to the msi file and start again the installation. A global 
solution is software developers to avoid the use of msi files or complex 
software installers that perform fragile system acrobatics, for their programs.

Original comment by mays...@hotmail.com on 26 Jan 2012 at 6:10