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.