November 15, 2009 at 12:49 Another open source
Then no one used these words. Not sure if I even knew their meaning then. For the first time , I learned about Vladimir Kladov ’s Key Object Library project, or just KOL before the institute, in one of two issues of the Programmer magazine, which my mother wrote to me in honor of going to the regional programming contest. The article was called " Count in the heart ... of your program!"»It seems in the same issue of the magazine, I first learned about .NET. Then, such exorbitant requirements for resources seemed almost a diversion of the software giant against the IT industry. (I still recall a laboratory friend of the same classmate, consisting of one mold, starting half a minute at the department on the Celeron 433 64MB hardware from under Windows 98. I was playing Diablo II on the same machine without brakes when the steam task was performed :)
And KOL was different. He emphasized the speed of work and the size of the executable file. It was not good at that time to download software updates of 10 megabytes each from the Internet. For those who wrote under Delphi, the choice was not great - either use the VCL - the standard visual library Delphi (by the way, its architect also worked on creating the .NET framework), or write on the windows API, the most desperate enthusiasts did this.
Not to say that VCL was terrible, it did a great job with medium to large projects. But for the small utilities, which the novice programmer writes most, he did not fully fit. The minimum size of the executable file was, depending on the Delphi version, from 250 to 350 kb and increased quite rapidly with the addition of various controls to the application. This was a consequence, first of all, of a highly branched tree of classes, where each control had up to a dozen parents. In addition, I could not forgive the VCL for launching an empty application on it on my very first AMD K5-100 computer for about half a second, and the application on MFC (the standard framework in old visual studios) started almost instantly :)
Apparently Vladimir Kladov was worried about the same problems and at some point he set about writing XCL - a library built on the same principles as VCL, but carefully respecting the size of the executable file. But I must say that there are a lot of ways to affect the size of the executable (not counting the post-processing in the form of packers). Different code that performs the same task can vary greatly in size. However, work on this project did not last long (judging by the history of changes , a year), when the inefficiency of this approach became apparent. A new attempt to rethink the compact framework device was KOL.
The main know how approach of KOL was to imprison the functionality of all standard controls in onePControl class. At first glance, this seems nonsense when one class is responsible for the directory tree and button, but it worked. The whole secret was in different designers for different controls. The add-on to everything was MCK, an add-on to VCL that generated output code to create similar KOL components. Those. you could work in the familiar Delphi environment, throw buttons on the form, and MCK generated code for you for the same form, but on pure KOL. At the same time, the starting size of the application was 20 kb or 10 kb with a little trick, replacing the Delphi system libraries, which could be used in the "releases".
The community developing the library was small but friendly. Of course, Vladimir made the biggest contribution to the development of the library, but it was difficult to overestimate the role of others. In this friendly team, still very green, I joined the first courses of the institute. The main forum, in combination with a bug tracket, was on the site delphimaster.ru . All commits in the form of diffs made using the utility written by Vladimir were made by everyone interested (I still don’t know if its format of diffs is compatible with other open source analogs). New versions were released by our permanent team leader. The license under which the library can be used seems to have never been discussed. The official website still has a simple and understandable “Provided free of charge, with source code”.
A lot of auxiliary libraries were written and ported under the framework , all in compliance with the main ideology.
As in any other Open Source project, everyone found something in their development. Vladimir had and has quite a few small and medium-sized projects, all built on KOL:
My goals, of course, were completely different. For me it was primarily a practice in programming. Well, as they say now, just for fun. I made only 4 more or less significant contributions to the library. Since I still do not remember the chronology, I will list them in increasing order of importance.
The reason for writing is the very slow speed of the previous implementation. Since the new one did not support some types of fill that the old implementation supported, it was not enabled by default.
Of course, this was not the first or even the best library for downloading pictures under KOL. But it was very tricky :) The BMP JPG and GIF format downloader took no more than one kilobyte in the compiled view. How is this possible? The OLE automation functions OleLoadPicture were used. Of course, this was not an option for graphic editors, at least this function could not load broken pictures. But for some installer, that was the most. But with PNG everything was more complicated. Of course, I took some library as a basis not for KOL (I don’t even remember which one), but I found a set of pictures for testing PNG on my own head and many formats did not work. I had to finish it. Then I found out what PNG format is capable of and how different it can be (hello, ie!).
KOL allowed any element to draw itself of any shape. What Vladimir realized, and later I improved, was not in VCL except for windowless controls (i.e. pictures and labels). My improvement was as follows: previously the transparent element was painted on itself by the parent, and then on top of itself. If there were 20 transparent elements, each of them painted a parent on itself. My decision was not to draw child elements, but to send a request for redrawing to a parent who would draw all the children on himself. It sounds simple, but in fact it was very difficult to get GDI to do something for which it was not intended. Nevertheless, the achieved result, it seems, worked correctly in at least 90% of cases and worked faster than the previous version.
Until now, this is the largest project that I have completed alone. Someone from the forum somehow demonstrated their achievements in porting the RB Controls library to KOL. By the way, the original RB Controls are used in at least one of the add-ons over IE (maxthon, it seems). The demo of the ported components looked like this:
Agree, pretty nice. Plus good customization options. But the speed of all this was far from amazing (you can see a compiled example ). As I understand it, the original RBs for VCL also did not shine. My further actions are not difficult to guess, I began to work on my version of controls, similar to RB Controls externally, but completely different inside - GRush Controls.
As a result, we got controls with several types of fill, smooth flowing when pressed and hovered, smoothed round corners (hello, css3!), With the ability to use both text with a shadow and a picture. And all this worked hellishly fast even on my then Celeron 500. The set of components included: Button, Panel, CheckBox, RadioBox, Splitter (slider for user resizing of 2 other components), ProgressBar.
The work turned out to be useful for the first project, a quick gradient fill. All critical sections were thoroughly tested and much was written in assembler using MMX. After rereading some points of the changelog now, such nostalgia takes:
Here are some “shocking" facts:
- The demo of RB Controls, when deployed to the full screen, eats 7 meters of memory from me and up to 50 while resizing panels using a splitter.
- The GRush demo is almost the same (a compiled example ) at any window size it eats 850 Kb and during resizing up to 3 Mb. The secret to using for unchangeable surfaces of video memory, for variable - dib.
- Gradient panel measuring 1900 × 1100 pixels ( such) with rounded, four times ironed corners of 100 × 100 pixels each, is capable of rendering 70 times per second. Without round corners up to 320 times. This is on a single Athlon 5200 core. I must say that this is a “from scratch” rendering that occurs when the component is resized or created. If nobody touches the component, it draws itself from the caching surface much faster.
Separate mention are the visual wizards for configuring components in MCK. As I said, MCK components are essentially the same VCL components. This does not play a big role for buttons and panels, and both are in both frameworks (KOL and VCL). But there are no GRush controls for VCL, but they have a lot of settings. And to make a full-fledged editor, I would have to port them to VCL. The idea itself is not bad, but not for the sake of the settings editor! I acted differently. As far as I know, before me, and possibly after, no one did this. I launched a KOL form with real GRush controls as an editor. Those. the KOL form worked in the Delphi environment itself. The editor turned out like this:
I think I told everything that I was going to. The story was inspired by yesterday’s poll on the Haber, “Are there any authorities for you in programming,” which the author apparently preferred to hide (Surveys are traditionally negative for us, yes).
By the way, I stumbled upon my old ftp on one interesting archiver . I’m not even sure that I did it myself. It has several demo projects on VCL vs KOL and VCL & RB vs KOL & GRush. You can compare the size of programs, download speed and memory consumption.
And KOL was different. He emphasized the speed of work and the size of the executable file. It was not good at that time to download software updates of 10 megabytes each from the Internet. For those who wrote under Delphi, the choice was not great - either use the VCL - the standard visual library Delphi (by the way, its architect also worked on creating the .NET framework), or write on the windows API, the most desperate enthusiasts did this.
Not to say that VCL was terrible, it did a great job with medium to large projects. But for the small utilities, which the novice programmer writes most, he did not fully fit. The minimum size of the executable file was, depending on the Delphi version, from 250 to 350 kb and increased quite rapidly with the addition of various controls to the application. This was a consequence, first of all, of a highly branched tree of classes, where each control had up to a dozen parents. In addition, I could not forgive the VCL for launching an empty application on it on my very first AMD K5-100 computer for about half a second, and the application on MFC (the standard framework in old visual studios) started almost instantly :)
Apparently Vladimir Kladov was worried about the same problems and at some point he set about writing XCL - a library built on the same principles as VCL, but carefully respecting the size of the executable file. But I must say that there are a lot of ways to affect the size of the executable (not counting the post-processing in the form of packers). Different code that performs the same task can vary greatly in size. However, work on this project did not last long (judging by the history of changes , a year), when the inefficiency of this approach became apparent. A new attempt to rethink the compact framework device was KOL.
The main know how approach of KOL was to imprison the functionality of all standard controls in onePControl class. At first glance, this seems nonsense when one class is responsible for the directory tree and button, but it worked. The whole secret was in different designers for different controls. The add-on to everything was MCK, an add-on to VCL that generated output code to create similar KOL components. Those. you could work in the familiar Delphi environment, throw buttons on the form, and MCK generated code for you for the same form, but on pure KOL. At the same time, the starting size of the application was 20 kb or 10 kb with a little trick, replacing the Delphi system libraries, which could be used in the "releases".
The community developing the library was small but friendly. Of course, Vladimir made the biggest contribution to the development of the library, but it was difficult to overestimate the role of others. In this friendly team, still very green, I joined the first courses of the institute. The main forum, in combination with a bug tracket, was on the site delphimaster.ru . All commits in the form of diffs made using the utility written by Vladimir were made by everyone interested (I still don’t know if its format of diffs is compatible with other open source analogs). New versions were released by our permanent team leader. The license under which the library can be used seems to have never been discussed. The official website still has a simple and understandable “Provided free of charge, with source code”.
A lot of auxiliary libraries were written and ported under the framework , all in compliance with the main ideology.
As in any other Open Source project, everyone found something in their development. Vladimir had and has quite a few small and medium-sized projects, all built on KOL:
- ImgSearch - A program for finding and deleting similar images. At one time, it worked better, possibly known to you imageDupeless.
- Zoomer - ( Caution , something tells me that there is a virus on the page. The program itself is in order). Fast, even very, image file viewer with its unique scaling algorithm using MMX, which Vladimir did not agree to give out even under torture :)
- EmuZWin - Spectrum Emulator (S48 and S128). Supports Multicolor (48K, 128, 128 / + 2 / + 3, Pentagon), Smooth Scale, and a very long list of other things :)
My goals, of course, were completely different. For me it was primarily a practice in programming. Well, as they say now, just for fun. I made only 4 more or less significant contributions to the library. Since I still do not remember the chronology, I will list them in increasing order of importance.
New rendering for the GradientPanel control
The reason for writing is the very slow speed of the previous implementation. Since the new one did not support some types of fill that the old implementation supported, it was not enabled by default.
TinyPictures library
Of course, this was not the first or even the best library for downloading pictures under KOL. But it was very tricky :) The BMP JPG and GIF format downloader took no more than one kilobyte in the compiled view. How is this possible? The OLE automation functions OleLoadPicture were used. Of course, this was not an option for graphic editors, at least this function could not load broken pictures. But for some installer, that was the most. But with PNG everything was more complicated. Of course, I took some library as a basis not for KOL (I don’t even remember which one), but I found a set of pictures for testing PNG on my own head and many formats did not work. I had to finish it. Then I found out what PNG format is capable of and how different it can be (hello, ie!).
Replacing the old transparency system
KOL allowed any element to draw itself of any shape. What Vladimir realized, and later I improved, was not in VCL except for windowless controls (i.e. pictures and labels). My improvement was as follows: previously the transparent element was painted on itself by the parent, and then on top of itself. If there were 20 transparent elements, each of them painted a parent on itself. My decision was not to draw child elements, but to send a request for redrawing to a parent who would draw all the children on himself. It sounds simple, but in fact it was very difficult to get GDI to do something for which it was not intended. Nevertheless, the achieved result, it seems, worked correctly in at least 90% of cases and worked faster than the previous version.
Grush controls
Until now, this is the largest project that I have completed alone. Someone from the forum somehow demonstrated their achievements in porting the RB Controls library to KOL. By the way, the original RB Controls are used in at least one of the add-ons over IE (maxthon, it seems). The demo of the ported components looked like this:
Agree, pretty nice. Plus good customization options. But the speed of all this was far from amazing (you can see a compiled example ). As I understand it, the original RBs for VCL also did not shine. My further actions are not difficult to guess, I began to work on my version of controls, similar to RB Controls externally, but completely different inside - GRush Controls.
As a result, we got controls with several types of fill, smooth flowing when pressed and hovered, smoothed round corners (hello, css3!), With the ability to use both text with a shadow and a picture. And all this worked hellishly fast even on my then Celeron 500. The set of components included: Button, Panel, CheckBox, RadioBox, Splitter (slider for user resizing of 2 other components), ProgressBar.
The work turned out to be useful for the first project, a quick gradient fill. All critical sections were thoroughly tested and much was written in assembler using MMX. After rereading some points of the changelog now, such nostalgia takes:
[+] Добавлен символ условной компиляции USE_MEMSAVEMODE (включен по умолчанию). Думаю все-же не так накладно с точки зрения производительности создавать новые Paterns при наведении или нажатии мыши, а удалять сразу как они не будут нужны. В больших проектах может сильно уменьшить количество используемой памяти (и видео кстати тоже).
[*] Процедура BitmapAntialias4X переведена в MMX на асамблер (прирост ее скорости вдвое), что однако не сильно увеличило общую производительность при больших значениях XXX_BorderRoundWidth/Height. По видимому узкое место - GDI, поэтому добавлена функция BitmapAntialias2X (в том числе и с MMX) и по умолчанию теперь используется она (если конечно не отключен новый символ условной компиляции USE_2XAA_INSTEAD_OF_4XAA).Here are some “shocking" facts:
- The demo of RB Controls, when deployed to the full screen, eats 7 meters of memory from me and up to 50 while resizing panels using a splitter.
- The GRush demo is almost the same (a compiled example ) at any window size it eats 850 Kb and during resizing up to 3 Mb. The secret to using for unchangeable surfaces of video memory, for variable - dib.
- Gradient panel measuring 1900 × 1100 pixels ( such) with rounded, four times ironed corners of 100 × 100 pixels each, is capable of rendering 70 times per second. Without round corners up to 320 times. This is on a single Athlon 5200 core. I must say that this is a “from scratch” rendering that occurs when the component is resized or created. If nobody touches the component, it draws itself from the caching surface much faster.
Separate mention are the visual wizards for configuring components in MCK. As I said, MCK components are essentially the same VCL components. This does not play a big role for buttons and panels, and both are in both frameworks (KOL and VCL). But there are no GRush controls for VCL, but they have a lot of settings. And to make a full-fledged editor, I would have to port them to VCL. The idea itself is not bad, but not for the sake of the settings editor! I acted differently. As far as I know, before me, and possibly after, no one did this. I launched a KOL form with real GRush controls as an editor. Those. the KOL form worked in the Delphi environment itself. The editor turned out like this:
I think I told everything that I was going to. The story was inspired by yesterday’s poll on the Haber, “Are there any authorities for you in programming,” which the author apparently preferred to hide (Surveys are traditionally negative for us, yes).
By the way, I stumbled upon my old ftp on one interesting archiver . I’m not even sure that I did it myself. It has several demo projects on VCL vs KOL and VCL & RB vs KOL & GRush. You can compare the size of programs, download speed and memory consumption.