|
|
Developer's info
HyperView running in Mozilla & IE. and running 2 concurrent
& listening Non blocking java.nio servers.
| HyperView: A 100% Java(tm) pure AWT layer API which was designed with the idea of multiplayer gaming in mind. A short description would be that it is a highly optimized AWT GUI,this is a simplistic analogy because there is alot more to HyperView than is apparent on the surface. A little history: HyperView began after the release of JDK1.02. That was the pre Swing days, and there were many issues related to Event models and multithreading under different operating systems. Thus after several years of development in 1999, the old code was completely thrown out. This was not a waste as there were many valuable lessons learned at that juncture, and this served as a valuable guidepost of the dos and don'ts of Java(tm) development. Sun realized the JDK1.02 event model had issues, and thus released the 1.1 event model. The 1.1 Event model too has issues most of which are unknown to most Java(tm) programmers. We won't cover that indepth subject here as it is a complex and engrossing subject, but suffice that the end result was the complete rewrite of several aspects of the underlying Java(tm) mechanics, and those mainly being Components: Except for the parent Frame, HyperView does not use standard components because there were memory issues with them. Instead it uses "Gobs" AKA "Graphcs Objects" which are are "Lightweight Components" that essentially encapsulate a graphics image (jif/lpeg/png etc.). Gobs can for example be created from a simple gif or jpeg file that can be edited with a simple paint program, or created via a MemoryImageSource. Events: There are little known issues with the AWT-Event Thread & listener interface. Mouse Events The standard listener interface has mostly unknown but potentially show stopping issues. Keyboard events: As with the mouse this has issues which could also be show stopping. HyperView uses the container down approach to dispatch mouse and key events. Thus the container is the only real listener and it hands the event to the respective ** Component. The HyperView totally controls Events and does all relevant computations rather than let the JDK do them. Because of monolithic and thoughfill design, HyperView is much more efficient at doing many things than the underlying JDK. Embedding: Gobs can be easilly embedded on each other for complex GUI implementations. Layering: All Gobs have layering/z order capability that can be enabled. SuperBitmaps: SuperBitmaps are bitmaps that are larger than the visible display. They can be scrolled, and the HyperView has a superior ***smooth scroll. X/Y/Z space. The HyperView is in effect 2.5D which is a compromise between the flatness of 2D, and the performance hit of 3D. It does its scaling on the fly and Keyboard Focus: Because the luxury of the JDK1.4x keyboard focus methods didn't exist at its conception, HyperView controls the focus internally. Additionally the cursor is a gif image that can be easilly altered via a simple paint program. Rendering & Thread preemption: HyperView does all graphics rendering and thus there is never any need to call the paint method. (Thought one is supplied) HyperView does all its rendering inline. Further, it also takes care to do all Thread preemption & timing. This ELIMINATES races such as those that infests many Java(tm)programs. Because of its design, rendering in HyperView is faster than thu underlying operating system. HyperView can replace or change 100% of all **Components smoother and faster than for example MS windows! All inactive Threads do a proper wait() and thus are completely removed from the underlying task sheduler when not active. NetXec & MultiThreading: HyperView was designed with multithreading in mind. NetXec is a unique Thread group that various Threads can register with and thus be monitored by. It is extremely efficient and greatly eases debugging multi thread issues. Double Buffering: All graphics in HyperView are 100% double buffered All rendering is done offscreen and frame switching is accurately timed for superiorly smooth graphics. Preferences API: HyperView implements the very latest Preferenecs API so state values can be easilly save directly to the Windows registry or maintained accordnig to the methods of your particular operating system. Animation: HyperView was designed with animation in mind. Its AnimGob.class allows you to easilly create frames to be animated in a simple paint program. Splines: HyperView has its own implementation of X/Y/Z Splines. This means you can accurately control the X/Y/Z movment of Background images: Background images are totally changable on the fly and can be URL based. Stack based display construction & change dispatch: HyperView runs in different stack frames starting at stack frame 1. Thus in the event of a fatal error it can usually recover by returning to the previous stack frame. (See next entry) Guru exception handler: HyperView traps all exceptions and the underlying Guru methods can recreate the display and thus usually recover. Embedded Multithreaded NON blocking java.NIO server. In our tests, with each connecting node using an 8K ByteBuffer, 4K for input and 4K for output, on a stock PC running Windows XP & a gig of RAM, the HyperView could handle over 7200 concurrent connections! The Server will also run stand alone. This is a multithreaded NIO server makes the input and output totally independent as well as connecting, disconnecting, and non activity timeout. Thus the server runs 5 threads,or what we call the Penta Threaded model. X type Popup Menu: HyperView has a built in and changable popup menu. Real time clock & taskbar: As the title says. Color Cycled text: An example is the title on the demo. Accurate Runtime length timer: You can tell the HyperView exactly how long to run, and when it stops running change the display and then run again. Runs as Applet Or application with having to recode. Also runs as a secure JDK1.2+ securely signed applet. Graphically modifyable packet editot. Externalizer.class Is simply the cleanest implementation of Java(tm) Serialization and allows the setup of Object Serialzation instructions with the absolute highest degree of runtime efficiency because serialization is reduced to the absolute minimum amount of instructions needed as referenced directly by the calling class. Concurrent Object Registry Allows you to set which objects have permission to run and gives each Object a unique branch index. Graphically modifiable server state machine. "Binary" based server state machine . (in progress linking to ObjectRegistry/Externalizer/StateMachine) ** HyperView doesn't use standard Components; it has its own lightweight components implementation.. *** A smooth scroll is a much more accurate shifting of the display that a standard scroll. This is because HyperView rendering is accurately timed. |
This site is 100% W3.org HTML
4.01 compliant.
