Alpah Demo 6

Hi, The new alpha you can get here: http://www.geocities.com/zhamilton1/SafireAlphaTest6.zip The speed has been improved and I have now enabled dragging of windows. Enjoy

Work, Work, Work

Here is another demo: http://www.geocities.com/zhamilton1/SafireAlphaTest5.zip All modules are dll's apart from the Screens executable. This gives a great speed boost which will improve soon even more when I implement a better drawing model. The code needs to be cleaned a bit more since the move to dlls was a little rough, but I am sure that things will be fine. I need to improve the input model as well so that there is a real thing as an active window so that keyboard input can be sent to a specific window instead of to all windows. Also each window will have an active control. Note that these are handled directly by the classes so they can all be overriden by modifying the classes. Thats the beauty of Screens.

Alpha Demo 4

Hi, I have been busy since last night and I give you the 4th alpha demo here at the following link: http://www.geocities.com/zhamilton1/SafireAlphaTest4.zip The demo will show 4 windows which you can choose any window (by its title) and drag them around. I have disabled dragging animation on purpose because of the slow speed. When I make Safire a dll, I can re-enable the animation which will probably be in the next demo. You can tap on a window to bring it to the front. From a development point of view, I have updated the UIElement class to support pen input and the UIWindow class which is derived from UIElement deals with the dragging of the window. As you can see progress is much more visible now and I am thrilled with the progress in these last few days. The slow speed of the demo is because of constant module launching. While the speed did improve because the kernel is a dll, its now slower because I do much more Safire calls which means a constant module launch for each Safire call. Once I make Safire a dll, the speed will suddenly come back. I hope I can do this soon so that we can put the speed bumps behind us and focus on some good functionality. Remember that the reason that there is no text is because I still have not decided which text engine I want to use for Screens... Remember my first demo back in 2002, I feel like I done a full circle but with the addition of object oriented storage and color ;)

Wow

Three posts in one day... Ok, the reason I am posting is to tell you all that I have just uploaded to SVN changes where the kernel (Xec) is now to be compiled as a dynamic dll when compiling for windows. This makes things much faster and I can see all but the 'loader' becoming dll's because of the speed. How faster? I guess around 3-4x faster then before. There is about a 25 millisecond hit when launching executables and nearly no hit when using dll's. For PalmOS, this does not matter much and the setup for compiliation is still exactly the same. I am glad that the speed did not require a major change but rather a small change to become a dll. I was scared at first since this is my first write of a dll but it worked the first time I tried it. Remember that Screens is not about speed but I do expect Screens to be fast enough to enjoy productivety without feeling slugish. Just remember that windows was not exactly fast neither was the world wide web and we can see what happended with those projects. They got faster as time went by. Performance realy is not that important as people make it.

Project Status

Hi, The project status is actually doing quite well. There is alot of work ahead but if you compare the amount of work done in the last few months, the code is maturing nicely. Now that windows have objects, even if they are simple objects (no skinning), its a step forward to the windowing working. I will be working now on the input queue where windows will receive events such as tap and key events. I have not finished designing this but I am sure I will find a solution soon enough. I know the speed is currently terrible on the windows version because of sub launching. This will be improved after I finish the input code. I will be also porting Safire when I finish the input code so that you can start running the demos on both windows and PalmOS. I am considering writing a linux port so those running on linux can also have a turn and see the flexability of the Screens platform. The advantage is that I only have to maintain platform dependent code rarely since most of the code is platform independent. So please dont judge the speed of Screens untill we see it running on PalmOS since most the speed bump is coming from the launching of processes on windows which is a platform dependent thing. On PalmOS this is much faster because everything is in RAM.

Update - Third Alpha

Hi Everyone, Sorry for the lack of posts, I was on a buisness trip in london all last week so I had no time to work on Screens at all. However I am working harder this week to fill in the gap. Here is the third alpha: http://www.geocities.com/zhamilton1/SafireAlphaTest3.zip I have also uploaded to SVN the UIWindow class and did some maintence on the kernel code to get the whole thing to work together. The demo now actually uses an object for each window. Every time you start the demo, you can control the position of a single window. Then exit and start the demo again to control a new window. It shows the persistance and might give you a glipse into the direction I am going. I know its not much and that the speed is terrible, but things are moving forward nicely.

Update - PalmOS Xec Code Updated

Hi, I just finished writing the updated kernel platform dependent code for PalmOS. Although I have not tested it and will not test it untill I finish porting the Safire platform dependent code, the kernel code does compile. Just remember if you are using PODS to add the Interface folder in the includes header list and the KERNEL_MODULE define if you are compiling the kernel. I have worked on Safire as well and now the layers can be saved and restored as you can see from the demo below: http://www.geocities.com/zhamilton1/SafireAlphaTest2.zip The same instructions as before, run Safire.exe with Xec.exe in the same folder. When you drag the mouse, one of the windows will move around. Close the application and restart it and the window will be in the exact location as before. Its not remembering just the window location but also how its drawn. It allows me to make starting/closing Screens to be very fast since no 'saving' of state is needed. Thats what the object persistance is for. The Safire API now works nicely. I know the speed is not something but I do have some ideas how to improve it in the future for the windows platform but currently platform dependent optimizations are not at the head of my list. Let it work first slow and then optimize it.

An Alpha Demo

OK, Its not fair for all of you... even if it is taking forever to finish, you are entitled to an all or nothing where either I shut up and release it in one big swoosh or I update you regulary with the development. I have decided to regulary display the results of my work and you can decide if its lame and will take me forever or appreciate the improvements as time goes by. You can find the files at: http://www.geocities.com/zhamilton1/SafireAlphaTest1.zip To run the demo, extract both files to the same folder and run Safire.exe Drag the mouse around in the window, to see the alpha blending effects. The demo is painfully slow because its using the display API. I will see how much I can improve the speed but remember that Screens is not about speed but rather about functionality and ease of use but there is always a way to improve speed so I dont see it high priority at the moment. It uses the windows 3.1 look just to feel a bit nostalgic. There are two layers here where the window layer is moved. Both layers are drawn once and then copied to the display each time you drag the mouse. The three windows are all in one back layer for simplistic reasons but I am sure I will start experimenting with multiple movable windows in the future. Currently the shared memory data source is not implemented but the shared memory component is implemented. I know this project is very technical which is true for most operating systems in thier early days. It can only get more interesting as time goes by... Enjoy!

Update - Shared Memory IPC

OK, The windows porting layer of Screens now has the Shared Memory IPC (Inter Process Communication). It makes things a bit faster but the best change was to allow CoreObjectOpen and CoreObjectUpdate to write directly to the store and skipping the IPC. This makes it much faster however it will be much faster when I add the shared memory data source. I am going to have to wait a while before I can create a demo or set of nice screenshots... But Jacob I do like your idea. I wont able to do text because Screens does not have a text engine yet (I still have not decided which text engine I should do/support). So most of the demos or screenshots wont have any text in them. I am now going to work on the rest of the data source functionality which is mostly the API function CoreObjectSource. The idea of the data source is that if an object has a different data source then in the store itself like a shared memory allocation, when you read/write using CoreObjectRead/CoreObjectWrite, it will read from the data source (like shared memory) instead of from the store. This will allow layers to exist in shared memory without changing any of the 'user' code. I have not decided yet if I will allow to change the data source via user code but to make an object use shared memory, you will just call CoreObjectSetAsTemporary on an object and everything else is transparent. If you call CoreObjectNew with no parent (NULL), the object is created as default temporary and therefore the object is going to use shared memory. Once I finish implementing the shared memory data source, I will need to add an initialize function which will go through the entire object storage on startup and destroy all temporary objects (since thier handles dont exist anymore). The destructor method is not called on such objects but this case should only happen if Screens did not shut down correctly. When you shut down Screens correctly, it will find all temporary objects and call the destructor on them. This functionality should make layer drawing not just faster but easy to manage.

Update - Shared Memory

OK, I am writing alot of code to handle shared memory so that temporary objects dont flush data to the disk all the time. It was paintful to drag a rectangle on-screen and see the hard-drive spinning full speed. The tasks are as follows: 1. Replace the IPC (Inter Proccess Communication) file with a shared memory implementation of a fixed 4K size 2. Add data source functionality with functions CoreObjectSource and CoreObjectOffset 3. Add Shared Memory data source The idea is that I will expose to modules the actual file position of objects data stream so that the read and write data does not need to pass through the IPC. The functions were available anyway to modules so there should be no problem there and it will increase the speed of Screens hopefully. Once I finish adding the shared memory data source, I will able to create layer objects and not have to worry about managing thier memory through methods since it will be supported directly inside the kernel. Once that is done, I will re-evaluate the speed so that I can decide the drawing model once and for all. About the screenshots... The truth is that I dont know what to show in the screenshot since there isn't realy anything visible. Its mostly the platform code and currently only runs on windows. Any ideas what to display?