Another open source
Then no one used these words. I'm not sure that I knew their meaning at all then. For the first time about the project of Vladimir Kladov “Key Object Library”, or simply KOL, I found out before the institute, in one of the two issues of the magazine “Programmer”, which my mother wrote to me in honor of going to the programming contest in the region. The article was entitled “ Stake in the Heart ... of its program! "It seems in the same issue of the magazine, I first learned about .NET. Then, such exorbitant resource requirements seemed almost a diversion of the software giant against the IT industry. (I still remember the laboratory friend of a fellow student consisting of a single mold that runs half a minute at the department on the Celeron 433 64MB hardware from under Windows 98. I played on the same machine in Diablo II without brakes when the task for a couple was done :)
And KOL was different. He put in the forefront 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 that wrote under Delphi, the choice was not great - either use VCL - standard Delphi visual library (by the way, its architect also worked on creating the .NET framework), or writing on windows API, the most desperate enthusiasts were doing it.
Not to say that VCL was terrible, it coped well with projects from medium to large. But for small utilities, which a novice programmer writes most, he did not fit fully. The minimum size of the executable file was, depending on the version of Delphi, from 250 to 350 KB and quite quickly increased with the addition of various controllers to the application. This was the result, above all, of a highly branched class tree, where each control had up to a dozen parents. In addition, I could not forgive the VCL that the empty application on it on my very first AMD K5-100 computer started 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 began writing XCL, a library built on the same principles as the VCL, but respectful of the size of the executable file. And I must say that there are quite a few ways to influence 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, the work on this project did not last long (judging by the history of changes , a year), when the ineffectiveness of this approach became apparent. A new attempt to rethink the device of a compact framework was KOL.
The main know-how of the KOL approach was to imprison the functionality of all standard controls in a single PControl class. At first glance, this seems to be nonsense, when one class is responsible for the directory tree and the button, but it worked. The whole secret was in different designers for different controllers. The MCK, a superstructure above the VCL, which generated the code for creating similar KOL components, was the backlog for everything. Those. you could work in the familiar Delphi environment, throw buttons on the form, and MCK generated you a code for the same form, but on pure KOL. In this case, the starting size of the application was 20 kb or 10 kb with a little trickery, a replacement for the Delphi system libraries, which could be used in “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. I joined this friendly team, still quite green, on the first courses of the institute. The main forum, in combination with the bug-track, was on the site delphimaster.ru . Commits, in the form of diffs made using the utility written by Vladimir, were made by all those interested (I still don’t know if its diff format is compatible with other open source counterparts). New versions released our permanent team leader. The license under which the library can be used seems never to have been discussed. The official website still says simple and understandable “Provided free of charge, with source code”.
A lot of auxiliary libraries have been written and ported under the framework, all in compliance with the main ideology.
As in any other Open Source project, everyone found something different in his development. Vladimir had and still has quite a few small and medium-sized projects, all built on KOL:
I, of course, had completely different goals. For me, it was primarily a programming practice. Well, as they say now just for fun. I made a total of 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 fills 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 images under KOL. But it was very tricky :) The BMP JPG and GIF format downloaders did not occupy more than one kilobyte in compiled form. How is this possible? The OLE automation features of OleLoadPicture were used. Of course, this was not an option for graphic editors, at least this function could not download broken images. But for some installer was the most. But with PNG everything was more complicated. Of course, I took some kind of library not for KOL as a basis (I don’t even remember which one), but then I found a set of pictures for testing PNG and many formats didn’t work. I had to finish writing. Then I found out what the PNG format is capable of and how different it is (hello, ie!).
KOL allowed any element to draw itself of any shape. What Vladimir realized, and later I improved, was not in the VCL except for windowless controllers (i.e., pictures and labels). My improvement was as follows: the transparent element used to draw the parent on itself, and then on top of itself. If there were 20 transparent elements, each of them painted a parent on itself. My solution was not to draw the child elements, but to send a request for redrawing to the parent, who would draw all the children on himself. It sounds simple, but in reality it was very difficult to force GDI to do something it was not intended for. Nevertheless, the achieved result seems to work correctly in at least 90% of cases and worked faster than the previous version.
So far this is the biggest project I have done alone. Someone from the forum participants somehow demonstrated their experience in porting to the KOL library RB Controls. 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, quite 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 the VCL also did not shine. My further actions are not difficult to guess, I began to work on my version of the controllers, similar to RB Controls outwardly, but completely different inside - GRush Controls.
The result was controllers with several fill types, smooth flowing when pressed and hovering, smoothed round corners (hello, css3!), With the ability to use both text with a shadow and a drawing. And it all worked like hell fast even on my then-celeron 500. The set of components included: Button, Panel, CheckBox, RadioBox, Splitter (slider for resizing by the user of 2 other components), ProgressBar.
The work was useful developments on the first project, fast gradient fill. All critical sections were thoroughly tested and much was written in assembler using MMX. Rereading now some items of changelog, such nostalgia takes:
I will give a few "shocking" facts:
- The RB Controls demo eats up to 7 meters of memory when I unfold it to full screen and up to 50 meters while resizing the panels using a splitter.
- GRush demo is almost the same ( compiled example ) for any window size it eats 850 KB and during resizing up to 3 MB. The secret is in using for unchangeable surfaces of video memory, for changeable - dib.
- A gradient panel with a size of 1900 × 1100 pixels ( such ) with rounded, four times ironed corners 100 × 100 pixels each, capable of being drawn 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 drawing from scratch, which happens when a component is resized or created. If nobody touches the component, it draws itself from the caching surface much faster.
Separate mentions are visual wizards of component settings in MCK. As I said before, MCK components are essentially the same VCL components. It does not play a big role for buttons and panels, both are in both frameworks (KOL and VCL). But GRush controls for VCL is not, and they have a lot of settings. And to make a full-fledged editor, I would have to port them to the 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 the KOL form with real GRush controllers as an editor. Those. the KOL form worked in the Delphi environment itself. The editor is:
I think I told all that was going. The story was inspired by yesterday's poll in Habré, "Do you have any authority in programming," which, apparently, the author chose to hide (We traditionally have negative polls, yes).
By the way, I stumbled upon my old ftp at one interesting archivist . Not even sure that I did it myself. There are 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 put in the forefront 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 that wrote under Delphi, the choice was not great - either use VCL - standard Delphi visual library (by the way, its architect also worked on creating the .NET framework), or writing on windows API, the most desperate enthusiasts were doing it.
Not to say that VCL was terrible, it coped well with projects from medium to large. But for small utilities, which a novice programmer writes most, he did not fit fully. The minimum size of the executable file was, depending on the version of Delphi, from 250 to 350 KB and quite quickly increased with the addition of various controllers to the application. This was the result, above all, of a highly branched class tree, where each control had up to a dozen parents. In addition, I could not forgive the VCL that the empty application on it on my very first AMD K5-100 computer started 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 began writing XCL, a library built on the same principles as the VCL, but respectful of the size of the executable file. And I must say that there are quite a few ways to influence 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, the work on this project did not last long (judging by the history of changes , a year), when the ineffectiveness of this approach became apparent. A new attempt to rethink the device of a compact framework was KOL.
The main know-how of the KOL approach was to imprison the functionality of all standard controls in a single PControl class. At first glance, this seems to be nonsense, when one class is responsible for the directory tree and the button, but it worked. The whole secret was in different designers for different controllers. The MCK, a superstructure above the VCL, which generated the code for creating similar KOL components, was the backlog for everything. Those. you could work in the familiar Delphi environment, throw buttons on the form, and MCK generated you a code for the same form, but on pure KOL. In this case, the starting size of the application was 20 kb or 10 kb with a little trickery, a replacement for the Delphi system libraries, which could be used in “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. I joined this friendly team, still quite green, on the first courses of the institute. The main forum, in combination with the bug-track, was on the site delphimaster.ru . Commits, in the form of diffs made using the utility written by Vladimir, were made by all those interested (I still don’t know if its diff format is compatible with other open source counterparts). New versions released our permanent team leader. The license under which the library can be used seems never to have been discussed. The official website still says simple and understandable “Provided free of charge, with source code”.
A lot of auxiliary libraries have been written and ported under the framework, all in compliance with the main ideology.
As in any other Open Source project, everyone found something different in his development. Vladimir had and still has quite a few small and medium-sized projects, all built on KOL:
- ImgSearch - Program for finding and deleting similar images. At one time, it worked better, perhaps imageDupeless known to you.
- Zoomer - ( Beware , something tells me that the virus on the page. The program itself is in order). Fast, even very, graphic image viewer with its unique scaling algorithm using MMX, which Vladimir did not agree to issue 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 :)
I, of course, had completely different goals. For me, it was primarily a programming practice. Well, as they say now just for fun. I made a total of 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 Drawing for GradientPanel Controller
The reason for writing is the very slow speed of the previous implementation. Since the new one did not support some types of fills 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 images under KOL. But it was very tricky :) The BMP JPG and GIF format downloaders did not occupy more than one kilobyte in compiled form. How is this possible? The OLE automation features of OleLoadPicture were used. Of course, this was not an option for graphic editors, at least this function could not download broken images. But for some installer was the most. But with PNG everything was more complicated. Of course, I took some kind of library not for KOL as a basis (I don’t even remember which one), but then I found a set of pictures for testing PNG and many formats didn’t work. I had to finish writing. Then I found out what the PNG format is capable of and how different it is (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 the VCL except for windowless controllers (i.e., pictures and labels). My improvement was as follows: the transparent element used to draw the parent on itself, and then on top of itself. If there were 20 transparent elements, each of them painted a parent on itself. My solution was not to draw the child elements, but to send a request for redrawing to the parent, who would draw all the children on himself. It sounds simple, but in reality it was very difficult to force GDI to do something it was not intended for. Nevertheless, the achieved result seems to work correctly in at least 90% of cases and worked faster than the previous version.
GRush controls
So far this is the biggest project I have done alone. Someone from the forum participants somehow demonstrated their experience in porting to the KOL library RB Controls. 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, quite 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 the VCL also did not shine. My further actions are not difficult to guess, I began to work on my version of the controllers, similar to RB Controls outwardly, but completely different inside - GRush Controls.
The result was controllers with several fill types, smooth flowing when pressed and hovering, smoothed round corners (hello, css3!), With the ability to use both text with a shadow and a drawing. And it all worked like hell fast even on my then-celeron 500. The set of components included: Button, Panel, CheckBox, RadioBox, Splitter (slider for resizing by the user of 2 other components), ProgressBar.
The work was useful developments on the first project, fast gradient fill. All critical sections were thoroughly tested and much was written in assembler using MMX. Rereading now some items of changelog, such nostalgia takes:
[+] USE_MEMSAVEMODE ( ). - Paterns , . ( ).
[*] BitmapAntialias4X MMX ( ), XXX_BorderRoundWidth/Height. - GDI, BitmapAntialias2X ( MMX) ( USE_2XAA_INSTEAD_OF_4XAA).I will give a few "shocking" facts:
- The RB Controls demo eats up to 7 meters of memory when I unfold it to full screen and up to 50 meters while resizing the panels using a splitter.
- GRush demo is almost the same ( compiled example ) for any window size it eats 850 KB and during resizing up to 3 MB. The secret is in using for unchangeable surfaces of video memory, for changeable - dib.
- A gradient panel with a size of 1900 × 1100 pixels ( such ) with rounded, four times ironed corners 100 × 100 pixels each, capable of being drawn 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 drawing from scratch, which happens when a component is resized or created. If nobody touches the component, it draws itself from the caching surface much faster.
Separate mentions are visual wizards of component settings in MCK. As I said before, MCK components are essentially the same VCL components. It does not play a big role for buttons and panels, both are in both frameworks (KOL and VCL). But GRush controls for VCL is not, and they have a lot of settings. And to make a full-fledged editor, I would have to port them to the 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 the KOL form with real GRush controllers as an editor. Those. the KOL form worked in the Delphi environment itself. The editor is:
I think I told all that was going. The story was inspired by yesterday's poll in Habré, "Do you have any authority in programming," which, apparently, the author chose to hide (We traditionally have negative polls, yes).
By the way, I stumbled upon my old ftp at one interesting archivist . Not even sure that I did it myself. There are 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.
Source: https://habr.com/ru/post/75261/
All Articles