*Major Rumour* Tommorow (29-03-07) Microsoft will have a big annoucement

Lol, well I knew that when they added the caveat 'since CES' that the announcements were gonnabe pretty small. What did they even announce at CES? :LOL:
 
This is the stupidest and lamest Microsoft invention ever.

Deepfish's answer to stuff like iPhone's zoomable webkit browser is?

Tada:

1) render web page on server side as BITMAP IMAGE
2) send BITMAP to mobile device (hello, increased bandwidth and latency)
3) user uses cumbersome joystick to move grey rectangle around and click on regions of interest, which are zoomed and rendered.

Microsoft would be better off throwing Pocket Internet Explorer out the window, and downloading and porting the open source version of WebKit which is what everyone these days is doing.
 
This is the stupidest and lamest Microsoft invention ever.

Deepfish's answer to stuff like iPhone's zoomable webkit browser is?

Tada:

1) render web page on server side as BITMAP IMAGE
2) send BITMAP to mobile device (hello, increased bandwidth and latency)
3) user uses cumbersome joystick to move grey rectangle around and click on regions of interest, which are zoomed and rendered.

Microsoft would be better off throwing Pocket Internet Explorer out the window, and downloading and porting the open source version of WebKit which is what everyone these days is doing.
Where did you get the technical implementation details from? I read this from the link above, which seems to contradict your increased bandwidth and latency comment:

"On current mobile browsers, it can typically take up to a minute or more for a Web page to render, however the Deepfish architecture only loads the user-specified portion of the page, providing much quicker page-load times, as detailed information is only retrieved as needed or in the background," Flake continued.
Mostly curious if you have the technical details or just reverse engineered it from press reports.
 
This is the stupidest and lamest Microsoft invention ever.

Deepfish's answer to stuff like iPhone's zoomable webkit browser is?

Tada:

1) render web page on server side as BITMAP IMAGE
2) send BITMAP to mobile device (hello, increased bandwidth and latency)
3) user uses cumbersome joystick to move grey rectangle around and click on regions of interest, which are zoomed and rendered.

Microsoft would be better off throwing Pocket Internet Explorer out the window, and downloading and porting the open source version of WebKit which is what everyone these days is doing.

Actually, it's not as bad as you said. Sending bitmap image does not necessarily increase bandwidth and latency, because many web sites now already have larger than 320x240 images across their front pages. Furthermore, some web pages are very complex, which can take considerable amount of time to render with limited computation power and memory. It can be much faster to display a bitmap than actually rendering a web page.
 
Actually, it's not as bad as you said. Sending bitmap image does not necessarily increase bandwidth and latency, because many web sites now already have larger than 320x240 images across their front pages. Furthermore, some web pages are very complex, which can take considerable amount of time to render with limited computation power and memory. It can be much faster to display a bitmap than actually rendering a web page.

No. Many existing mobile browsers and services already due image transcoding, they simply do not load up a complex web page with full resolution images. For example, the Sidekick on T-Mobile has a browser that uses a proxy server to scale images, as well as filter HTML to make it easier to render.

And in 2001, I invented, worked on and shipped an enterprise transcoding server that processed HTML, CSS, and images, into browser friendly HTML/WML, including reflowing text and inserting word breaks according to a device database of screen characteristics.

This type of proxy technique is not new or revolutionary, but shipping compressed and tokenized HTML plus rescaled images over non-3G networks is far less bandwidth than rendering a web page as a series of images. A typical HTML page can be massivedly compessed by tokenization, or even DEFLATE. B3D's frontpage compresses down to 7k using gzip. In contrast, a screenshot scaled to 176x220, and jpeg'ed to legible quality yields 22k, realistically for deepfish, it's going to be bigger unless they go for poor legibility or drop color. A smart HTML transcoder combined with client browser support can do alot better than 7k, and significantly reduce fetched image bandwidth, as well as assist the browser in rendering. For example, in my application, I pre-parsed, and pre-calculated all CSS element values, and shipped a byte-coded page with annotated rendering hints to the client, and I achieved very nice refresh rates on seriously slow J2ME execution environments.

Deepfish is simply a less intelligent way of doing what others have been doing for years. Simpler to implement, but less efficient and flexible. Just imagine how they're going to deal with AJAX applications for example. Do they even deal with ":hover" CSS properties when you move that rectangle/pointer over regions?
 
IIRC Opera Mini works like this too. However, the point of using a whole image (as in Deepfish) is to maintain maximum compatibility. Of course, there are many problems such as AJAX which are not supported in current preview version yet.
 
Back
Top