You can find the latest code uploaded via SVN at:
http://screensos.svn.sourceforge.net/viewvc/screensos/
I know that it looks like Screens is not moving anywhere, but there is an actual strategy involved even if it is taking a long time.
Let's recap:
2002-2008 = Wanted an application middleware, researching which programming model to use
2009-2011 = Figured out a new programming model: ComponentC programming model.
In the last half year I have spent time writing components.
The components separate for the first alpha into 3 parts:
1. Core
Core components is the basic core components of the system. CoreObject was the hardest component to write since it represented the programming model for Screens. The other core components were mostly easy.
2. File
This is where I am now. Writing components to parse files including xml using the component oriented model. I just finished a first draft of the file token parser which I will be using now for the xml component.
3. UI
This is the most exciting set of components (after CoreObject) that I want to write. I have had some years of researching drawing models (such as top down drawing) which I want to use in this middleware.
Once I finish these basic set of components, I can start making the more visual demos I made before. There are high and low points in any project. Here I am programming a strong foundation for later on. Once I finish the foundation I will able to move much faster in the alpha and beta releases.
I currently run the code in the iPhone simulator where it deals with multi-touch points, drawing a bitmap for each point while filling the screen with a gradient. As components come by I integrate them and check them in the demo. I think I will have some interesting things to show once I pass the second UI component set.
Because I tended to tell my ideas before implementing them, I am going the other route where I write something and then tell you about it.
Friday, April 08, 2011
Friday, April 01, 2011
Eating at a buffet
I finally found how to explain the advantage of Component C objects.
Using Component C objects is like eating a buffet. You have a choice of different foods which you can pile onto your plate in any combination or order that you want.
Using traditional object oriented languages/frameworks is like eating at a restaurant. You have a choice of different meals, each with its own combination of ingredients.
Using fixed meals is easier to use when the choice is small. But it does not scale. There is a reason why sandwich fast food places allow you to choose your own combination. Having a list of pre-fixed combinations becomes messy when it grows more than a few dozen options.
Thats why object oriented examples always work. They are a small selection of classes in use which work great just like a menu with 5-10 items works great as well.
Its when you have to manipulate over 50 items that things become complicated. So then they are separated into categories. But then you get to a point when categories need to be broken down into sub categories. Very quickly things can get out of hand. A complex system may have 200 classes that a developer needs to manage.
Do you derive your class from A, B, C, D, E or the other 50 options. Or maybe you go for containment which defeats the whole purpose of common components since you do not want to have to expose every possible interface that you want to support.
With Component C components. Its a buffet. You only offer a choice but do not control the combination of those choices. If the developer wants to make an object (like a plate) and attach to it (like putting food on a plate) a node and window component, you have a window that can be stored in a hierarchy of other nodes.
While I only have around 20-30 components, the advantage looks small. Its when I reach over the 100 component count that things become interesting. Every component only cares about what it needs to provide a specific feature or part of a feature. The combinations are defined by their usage. It scales.
UIWindow does not have to deal with hierarchy. CoreNode deals with hierarchy. Its separation of concerns. Components stay small because I don't have to stuff every feature I ever need in the same component.
Objects need to support reference count. Instead of stuffing it into CoreObject, it is handled in a separate CoreRef component.
As applications grow bigger, they will need to move to the buffet model. Al a carte.
Just like users are getting tired of fixed 1000 channel selections and prefer to choose what they want instead of tuning to a fixed channel that airs the show they want at a specific time.
Using Component C objects is like eating a buffet. You have a choice of different foods which you can pile onto your plate in any combination or order that you want.
Using traditional object oriented languages/frameworks is like eating at a restaurant. You have a choice of different meals, each with its own combination of ingredients.
Using fixed meals is easier to use when the choice is small. But it does not scale. There is a reason why sandwich fast food places allow you to choose your own combination. Having a list of pre-fixed combinations becomes messy when it grows more than a few dozen options.
Thats why object oriented examples always work. They are a small selection of classes in use which work great just like a menu with 5-10 items works great as well.
Its when you have to manipulate over 50 items that things become complicated. So then they are separated into categories. But then you get to a point when categories need to be broken down into sub categories. Very quickly things can get out of hand. A complex system may have 200 classes that a developer needs to manage.
Do you derive your class from A, B, C, D, E or the other 50 options. Or maybe you go for containment which defeats the whole purpose of common components since you do not want to have to expose every possible interface that you want to support.
With Component C components. Its a buffet. You only offer a choice but do not control the combination of those choices. If the developer wants to make an object (like a plate) and attach to it (like putting food on a plate) a node and window component, you have a window that can be stored in a hierarchy of other nodes.
While I only have around 20-30 components, the advantage looks small. Its when I reach over the 100 component count that things become interesting. Every component only cares about what it needs to provide a specific feature or part of a feature. The combinations are defined by their usage. It scales.
UIWindow does not have to deal with hierarchy. CoreNode deals with hierarchy. Its separation of concerns. Components stay small because I don't have to stuff every feature I ever need in the same component.
Objects need to support reference count. Instead of stuffing it into CoreObject, it is handled in a separate CoreRef component.
As applications grow bigger, they will need to move to the buffet model. Al a carte.
Just like users are getting tired of fixed 1000 channel selections and prefer to choose what they want instead of tuning to a fixed channel that airs the show they want at a specific time.
Saturday, March 19, 2011
Updates committed
Just to let you know that the latest code has been uploaded into the ScreensOS repository.
Friday, March 18, 2011
Moving along
Hi,
Sorry that I am consistently late in my updates.
I have been writing loads of components such as CoreQueue, CoreState, CorePool.
I am expanding the components and fixing bugs as I find them in existing components.
My next component is FileXml which will manage xml in an object oriented fashion but will have a twist where the objects are allocated by the caller instead of by the component itself. The xml file will also only be partially processed as needed. This should allow to load huge xml files without having to have the memory overhead.
There is currently a bug I think in XCode 4.0 where I can't seem to save my password in the repository settings for my SVN repository. When I find out how to save the password, I will update the latest code.
Sorry that I am consistently late in my updates.
I have been writing loads of components such as CoreQueue, CoreState, CorePool.
I am expanding the components and fixing bugs as I find them in existing components.
My next component is FileXml which will manage xml in an object oriented fashion but will have a twist where the objects are allocated by the caller instead of by the component itself. The xml file will also only be partially processed as needed. This should allow to load huge xml files without having to have the memory overhead.
There is currently a bug I think in XCode 4.0 where I can't seem to save my password in the repository settings for my SVN repository. When I find out how to save the password, I will update the latest code.
Tuesday, February 15, 2011
Update
I have been working hard on the data bitray component. I finished writing a first version of DataBitrayPaint. I am now working on enhancing the component to be able to compress/decompress/paint from one source to another. This should take me so time to figure it out and keep it simple. I will update you when I am done.
Friday, January 28, 2011
DataBitray
Uploaded the bitmap handling component (which is endian independent thanks to FileBinary component) which reads bitmap files.
However the component I want to talk about is the DataBitray component (packages/data in SVN). It allows compression and decompression of pixel buffers with some nice features:
1. In-place compression/decompression - Because the compressed data is always smaller or equal to the original data, compression can be done in place. Decompression is done backwards which also allows it to be done in-place. This allows to save the number of buffers needed for compression/decompression.
2. No header overhead - The Bitray compression is based on RLE but without the header problem. Pixels of the same value are compressed into two integers. So one pixel is one pixel, two or more pixels of the same value are always 2 pixels wide.
3. Simple design - No complex hash arrays, it allows for great locality since no static variables are needed and because it does in-place compression/decompression it only requires the buffer itself to be in the cpu cache, not two buffers.
4. Small output - A display filled with a single color is 8 bytes long. If each row has a single color, it is 8 bytes multiplied by the number of rows. This works well for user interface elements since they tend to have pixels of the same value.
5. Small code - The entire DataBitray component is less than 150 lines of code including comments! Its easy to implement and easy to read.
I plan to write soon DataBitrayPaint which will allow to do the alpha-blending on the target buffer instead of just overwriting the buffer when decompressing the data. The step after that is writing a component to manage the data-bitray buffers for images, so they can be easily embedded into the application without relying on file i/o. The idea is to isolate platform dependencies and this will be one way to avoid a platform dependency for simple user interface images.
However the component I want to talk about is the DataBitray component (packages/data in SVN). It allows compression and decompression of pixel buffers with some nice features:
1. In-place compression/decompression - Because the compressed data is always smaller or equal to the original data, compression can be done in place. Decompression is done backwards which also allows it to be done in-place. This allows to save the number of buffers needed for compression/decompression.
2. No header overhead - The Bitray compression is based on RLE but without the header problem. Pixels of the same value are compressed into two integers. So one pixel is one pixel, two or more pixels of the same value are always 2 pixels wide.
3. Simple design - No complex hash arrays, it allows for great locality since no static variables are needed and because it does in-place compression/decompression it only requires the buffer itself to be in the cpu cache, not two buffers.
4. Small output - A display filled with a single color is 8 bytes long. If each row has a single color, it is 8 bytes multiplied by the number of rows. This works well for user interface elements since they tend to have pixels of the same value.
5. Small code - The entire DataBitray component is less than 150 lines of code including comments! Its easy to implement and easy to read.
I plan to write soon DataBitrayPaint which will allow to do the alpha-blending on the target buffer instead of just overwriting the buffer when decompressing the data. The step after that is writing a component to manage the data-bitray buffers for images, so they can be easily embedded into the application without relying on file i/o. The idea is to isolate platform dependencies and this will be one way to avoid a platform dependency for simple user interface images.
Subscribe to:
Posts (Atom)