jeff_rigby
Banned
So something around 26+megs to support a Vita browser UI?patsu said:They will need a VM system for webkit. If so, they will need a more sophistcated memory manager such that the web browser cannot interfere with the games. Perhaps not a full subset but I am curious how they implement the Java runtime on Blu-ray side.
Also, I remember many small devices remove WebKit features so that it can run well in their environment. So WebKit is different for different devices.
That said, I think a native environment probably runs better at this point.
Video of Vita Interface showing:
Live functionality
Popup Chat notification from bottom with Icon and go directly to chat when touching the Popup user icon.
Browser is available from multiple windows as is the store. Cross game chat is available while playing a game (maybe only in "Live") or while using the browser.
The above would seem to indicate that webkit and ?Some? support libraries are always loaded as is a low level program to detect a request for chat (telepathy?)
There are multiple ways to accomplish this using a 26 meg OS cache. Cache in this case is misleading as the compiled to native language routines in webkit and support libraries are not copied to another memory location rather pointers to the routine are passed and it remains in the same memory location except for the instructions being executed in the CPU & CPU cache. It's called Zero Copy.
1)It may be a Python (JIT interpreted language) script in which case it would be very similar to Android functionally and isn't an Android OS core about 27 megs. Android runs a JIT script-like file that calls native language routines when needed for performance. Webkit Javascript (JIT script) does the same for the same reason. The model makes sense and has advantages.
2) If compiled native language it would quickly require more space as it would not use some of the routines in the 26 meg cache but provide machine language copies of them over and over. This is a more rigid harder to move from separate routine to separate routine method (to save memory) but faster. One large machine language program could reuse code but that requires more memory.
You could emulate the method Python uses to call native language routines but why go to the trouble. Only parts of a UI require performance, a JIT script calling native language routines has no performance issues, is easier to use and can be more easily separated into modules for different functions while using the fewest resources (Android model again).
Comparing advantages and disadvantages in Python vs. native language is similar to Andoid vs. native language. A discussion on the best method to use is out of my depth, I only understand the basic features in both. My understanding is that Androids biggest feature is memory efficiency.
Native language runs better but may not be the best choice. OLPC used Python for their OS UI and not because they wanted a cross platform OS. The PiViTI video editor uses Python and my understanding for that choice is because it is easier to use/write, uses fewer resources and is cross platform. A video editor requires a higher performance level than the UI in an OS.
The biggest thing I see is that the Android model is a large part of Gnome Mobile. An effort to use fewer resources has been behind new features since 2008. Xwindows and Matchbox are no longer a part of Gnome Mobile; that functionality has been moved to Glib and GTK resulting in greater performance while using less memory. Notice in this older block diagram of the Gnome Mobile core (need to remove Matchbox and Xwindows) the language bindings considered important; C and Python. The OLPC Sugar interface was written using Python in a day and functionally is identical with Vita Near. OLPC uses GTKwebkit which uses the core Gnome Mobile libraries and I'm certain the Vita does also
Everything I have read and that's hundreds of hours, points out the advantages in using Gnome Mobile/webkit support libraries and Python etc. These advantages are no accident, they are well thought out and have been coming since 2005 (Apple released webkit code) with the majority of the Hackers getting on board in 2007 caused by Alp Tolker of Collabora and the Gstreamer/Cairo webkit.
If as we suspect, PS Suite in large part depends on webkit and cross platform support libraries, Sony understands this and is moving to this model too.
The impression that the desktop would be based on HTML5 is in error, the desktop will support HTML5 but can be native language, or Python script, or Lua or anything Sony wants. But everyone is moving to support webkit and Hybrid webkit applications on the desktop. The XMB will be rewritten to support this (my opinion).
Edit: Currently the PS3 UI is written using XML.
Just looked at the files from PS3 firmware 3.55 again and the XMB UI is written using XML script. The GTK webkit has a library listing for XML which confirms that XML can be rendered with Cairo. Shouldn't be hard to change the current XML renderer to use cairo for rendering. If so, that is not an issue in the time it's taking for release. Edit on edit: The PS3 XMB may be using cairoGL for rendering since Firmware 3.0 (Sept 2009) and XML with Cairo backend.
Possible reasons for delays:
1) Waiting on Gnome & GTK3.2 as well as webkit2.
2) Ecosystem and XMB OS rewrites are extensive
3) Waiting on new applications and a rewrite of older applications.
Rumor is no major announcements at Gamescom. Prepare to be disappointed again.