Lately I've gotten the feeling that OpenGL is really going mainstream, including in KDE. We already have quite a few apps that are using it and it looks like more are coming.
However ATM many of those apps are reinventing the wheel by writing same generic code such as a texture class over and over again.
So I got the idea of creating some kind of KDE OpenGL library. It would have Qt-style API that KDE developers would be familiar with and would provide some common building blocks that would ease development of OpenGL apps. Right now I'm thinking texture and shader classes, maybe a camera class, some common functions, vector library (Eigen should be great for that) and perhaps an extension library (GLEW could be used). I don't want too many things though, it should still stay lightweight instead of becoming yet another fully featured 3d engine.
And it should be extensible. If your app needs e.g. cubemap textures, you should be able to write a CubemapTexture class that inherits from Texture class and provides necessary functionality. Such extensions could even be put into a common place so that other apps could copy them into their own source tree and use them without bloating the library.
The library probably needn't depend on KDE itself, just on Qt. This might make it interesting for pure Qt apps as well.
What do you think of that idea? Would you use such a library? Or know someone/something that might? Add your comments here.
Tuesday, August 28, 2007
Wednesday, August 22, 2007
Iconcache is Done :-)
The coding phase of the Summer of Code is now over (for two days already).
Within the last days I managed to add mmap-implementation which instead of opening/reading/closing cache files all the time maps them into shared memory and then just uses that memory. It seems to increase performance (of reading icons from the cache) by about 30%. More than I anticipated.
In the end I managed to get in all the features and ideas that I had, so the work on the icon/pixmap cache can be considered complete now. There might of course be some smaller performance tweaking and bugfixing and apidocs additions and so on, but I don't expect to do any bigger changes.
It also means that if you see a bug concerning icon loading or pixmap cache (I hope you won't ;-) then report it. Either contact me directly or add a comment here or whatever.
I still haven't gotten to doing the final benchmarking... maybe at the end of this week or in the next one...
Within the last days I managed to add mmap-implementation which instead of opening/reading/closing cache files all the time maps them into shared memory and then just uses that memory. It seems to increase performance (of reading icons from the cache) by about 30%. More than I anticipated.
In the end I managed to get in all the features and ideas that I had, so the work on the icon/pixmap cache can be considered complete now. There might of course be some smaller performance tweaking and bugfixing and apidocs additions and so on, but I don't expect to do any bigger changes.
It also means that if you see a bug concerning icon loading or pixmap cache (I hope you won't ;-) then report it. Either contact me directly or add a comment here or whatever.
I still haven't gotten to doing the final benchmarking... maybe at the end of this week or in the next one...
Friday, August 17, 2007
Iconcache status
Summer of Code is ending (the official deadline for writing code is 20th August) and so my work on the icon cache is also coming to an end.
Yesterday I committed the last crucial piece of code. The cache now periodically checks for icon theme updates, so as soon as you install some new icons, they should be used and the obsolete cache be discarded.
This means that the cache is now fd.o icontheme spec-compliant and all the necessary features should be implemented :-)
Some smaller things remain to be done, such as further performance improvements and final benchmarking. I hope to complete the code part in the coming days and most of benchmarking will probably be done after the 20th.
Speaking of benchmarks, I did some a few days ago. As you have probably heard already, perhaps the most extreme case is kfind which starts up in about 4 secs without the cache and in a bit less than 1 sec (of which just 300ms is icon loading) with the cache. That's with hot caches (i.e. operating system has cached some of the data already). With cold caches it's 12secs vs 2.5secs.
Dolphin uses quite a few icons as well. With cold caches it takes 3.9 secs with iconcache and 5.2 secs without it to start. With hot caches it's 1.2 vs 1.5 secs.
I also noticed about one second improvement (12 vs 13 secs) in full KDE session startup time (with Dolphin, Konqueror, Konsole and KBounce autostarted). I have to admit it's a bit less than I had hoped for, but KDE's startup time will probably be improved prior to 4.0 anyway. Anyway I will make further benchmarks to find out more accurate numbers.
The times are measured from when KPixmapCache contructor is called (which should be at most 100ms after the program is started) until the last find() call (after which the application should be ready to be used).
Yesterday I committed the last crucial piece of code. The cache now periodically checks for icon theme updates, so as soon as you install some new icons, they should be used and the obsolete cache be discarded.
This means that the cache is now fd.o icontheme spec-compliant and all the necessary features should be implemented :-)
Some smaller things remain to be done, such as further performance improvements and final benchmarking. I hope to complete the code part in the coming days and most of benchmarking will probably be done after the 20th.
Speaking of benchmarks, I did some a few days ago. As you have probably heard already, perhaps the most extreme case is kfind which starts up in about 4 secs without the cache and in a bit less than 1 sec (of which just 300ms is icon loading) with the cache. That's with hot caches (i.e. operating system has cached some of the data already). With cold caches it's 12secs vs 2.5secs.
Dolphin uses quite a few icons as well. With cold caches it takes 3.9 secs with iconcache and 5.2 secs without it to start. With hot caches it's 1.2 vs 1.5 secs.
I also noticed about one second improvement (12 vs 13 secs) in full KDE session startup time (with Dolphin, Konqueror, Konsole and KBounce autostarted). I have to admit it's a bit less than I had hoped for, but KDE's startup time will probably be improved prior to 4.0 anyway. Anyway I will make further benchmarks to find out more accurate numbers.
The times are measured from when KPixmapCache contructor is called (which should be at most 100ms after the program is started) until the last find() call (after which the application should be ready to be used).
Subscribe to:
Posts (Atom)