327 risposte a questa discussione

[p.nightmare]

sporadici
in b4 pellicola oscurante per correggere la feature

[nevione]

in b4 il nero dell'ipad e' troppo perfetto, quindi e' una feature per distinguere lo schermo dal bordo

[Sgobbone]

per correggere la feature

[nevione]

adesso arriva tigercoso e inizia il messaggio scrivendo 10 volte schermo ips

[Cyrano]

in b4 il nero dell'ipad e' troppo perfetto, quindi e' una feature per distinguere lo schermo dal bordo

http://www.hwupgrade...tyle_emoticons/default/asd.gif

ps visto che figata il tablet asus con la tastiera fisica ???!!!



C,òs,òlsò,s,òs

[rgart]

Per fortuna che lo prendo a metà aprile

[FradettII]

PC = paper cassette

[rimg]http://forums.radioreference.com/attachments/tavern-archives/20415-just-me-800px-pc_load_letter.jpg[/rimg]

LASERJET 4 PLUS.... miglior laser in B/N di sempre.

Ne dovrei ricevere una appena in ufficio da mio padre smettono di usarla

[matti157]

[eglio]

[johancruijff]

hei perchè avete uppato il 3d
.
.
.
.
.


non ricordo un lancio di iphone/ipad senza segnalazioni di problemi sporadici di qualche genere....fra 3 giorni l'avremo rimosso....capita quando si consegnano E vendono tablet da 10" in volumi.......gli 0 tablet 10" di Samsung, Hp, RIM consegnati e la manciata (rispetto a, mentre mia madre succhia cazzi, iPad) di Xoom prodotti/venduti difficile evidenzino simili problemi....

Citazione o lapsus? Oppure fai davvero parte della grande famiglia crapple?

[eglio]

Citazione o lapsus? Oppure fai davvero parte della grande famiglia crapple?

Lapsus mi hai sgamato, sono Jobs.

[johancruijff]

?[/url]":27e7ec8w]

Citazione o lapsus? Oppure fai davvero parte della grande famiglia crapple?

Lapsus mi hai sgamato, sono Jobs.

[TigerShark]

adesso arriva tigercoso e inizia il messaggio scrivendo 10 volte schermo ips

sempre detto che a me fotte sega dell'iPAD.
Ma giusto per farti contento lo schermo IPS del mio iphone non presenta alcun difetto del genere e ogni volta che vedo una merda di display SPERMOLED mi viene da ridere. http://www.hwupgrade...tyle_emoticons/default/asd.gif

[p.nightmare]

?[/url]":17sten8i] adesso arriva tigercoso e inizia il messaggio scrivendo 10 volte schermo ips

sempre detto che a me fotte sega dell'iPAD.
Ma giusto per farti contento lo schermo IPS del mio iphone non presenta alcun difetto del genere e ogni volta che vedo una merda di display SPERMOLED mi viene da ridere.

cvd http://www.hwupgrade...tyle_emoticons/default/asd.gif

[TigerShark]

?[/url]":2ti5ggr1]
sempre detto che a me fotte sega dell'iPAD.
Ma giusto per farti contento lo schermo IPS del mio iphone non presenta alcun difetto del genere e ogni volta che vedo una merda di display SPERMOLED mi viene da ridere.

cvd http://www.hwupgrade...tyle_emoticons/default/asd.gif

me l'ha espressamente richiesto nevione di citare lo schermo IPS, non potevo deluderlo.

[Killer application]

Sorry, Steve: iPhone 50 Percent Slower Than Android on Web


Android phones whisk users across the web in two-thirds the time that the iPhone takes, according to a study that compared the two top mobile OSes’ performance when downloading web pages.

The study, conducted by mobile-website–optimization company Blaze.io, involved more than 40,000 downloads of web pages belonging to the Fortune 1000 companies. The iPhone took 52 percent longer than Android to render full web pages. On average, Android phones took 2.1 seconds to render non–mobile-optimized web pages, while the iPhone took 3.2 seconds.

Android bested the iPhone on site-loading time a whopping 84 percent of the time.

The test included the Samsung Nexus S (Android 2.3), Samsung Galaxy S (Android 2.2), iPhone 4.3 and iPhone 4.2. Pages were loaded using a strong Wi-Fi connection, and each device loaded each Fortune 1000 website three times.

Oddly, the study found that the much-touted JavaScript improvements in the latest versions of Android and the iPhone had little real-world effect on these web pages.

“Our conclusion is that JavaScript performance doesn’t impact an average page load time,” the company wrote in the study. “Apparently, JavaScript is already so optimized that it doesn’t play a big role in the time it takes to load a page. It’s likely that rich AJAX applications benefit from these improvements, but users should not expect their casual web surfing to move faster.”

Both OSes clocked in nearly identical 2-second loading times for pages designed especially for mobile devices.

The company says the results surprised them.

We assumed that similar hardware specs and the same WebKit foundation would make iPhone and Android’s browsers perform equally. We assumed that a faster JavaScript engine equals a faster browser. We assumed that 3G would be way slower than WiFi, even under good conditions.
All of these assumptions have been proven wrong when we actually measured those scenarios. Without measuring, you don’t know when and where you need to optimize.

The Android-vs-iPhone-F1000-Paper includes more details on Blaze’s methodology and conclusions and will definitely be required reading for the ongoing battle between Android and iPhone fanatics.

http://www.wired.com... ... phone-web/

Problem?

[eglio]

Sì ok iPhone 4....ancora 3 mesi e poi tutto da rifare (lato hardware) con iPhone5 A5 dual core VS nuovi android Tegra2...vedremo. Lato software ancora 3 mesi e poi iOS5.

Risultati molto temporanei insomma. E unrelated con iPad2(che ha hardware da iphone5, non iphone4).

Poi, sì ok tempo di download delle pagine.....diversa cosa è la fluidità di utilizzo reale della pagina, di cui questo test non dice nulla...

E diversa cosa sono gli errori che il browser dei tablet android fa nelle pagine con roba HTML5/CSS3:

http://www.sencha.co... ... scorecard/

On the other side of performance testing, we also ran real world tests using our own CSS3 vs. Flash Ads page. As has been well publicized in the press, the Xoom does not ship with Flash so we were unable to see any Flash ads loading on our tests page. To make things doubly worse, the CSS3 animations are almost completely broken. We often found even for the most basic animations the browser skipped frames, incorrectly rendered elements, or didn’t run the animation to completion. If Animations were simply slow, that would be one thing, but the Xoom CSS3 Animation support faces basic correctness issues.

Moving to more complex animations, we next look at the more advanced CSS3 animations created by Sencha Animator. In an improvement from the Galaxy Tab, the animations actually render. On the other hand, again, they render incorrectly. We found that text sometimes doesn’t appear, parts of the artwork are clipped incorrectly, fonts are rendered poorly, and frames of the animation are dropped. For some of the 3D effects, the browser simply drops the 3D or tries and fails to render the effects. For anything but the most basic CSS transitions and animations the Xoom does not make the grade.

[size=150]It’s been nearly a year since crapple shipped the iPad and we’re still incredibly surprised that Google and Motorola have yet to build a mobile browser that has a correct and high-performance CSS3 implementation. The silicon power is definitely present to support it.[/size]

Unlike on the Galaxy Tab, Modernizr says the browser has SVG and in fact we are able to successfully test SVG. It performs reasonably well, allowing you scale the vector artwork quickly. We next look at Canvas by checking out a github network graph. Like on the Galaxy Tab the graph renders perfectly, and reasonably quickly[size=150]. We did find that interacting with Canvas elements didn’t always work how we thought it would. The browser often starts to make big blue selection rectangles instead of passing a click event to the DOM. [/size]We also checked out Canvas Cycle on the device and we’re surprised that it works. The framerate isn’t great but it does actually work. So generally speaking, Canvas support gets a gentleman’s C.

Finally we test embedded HTML5 audio and video. We are able to get HTML5 audio to work, [size=150]although we find that sometimes the audio plays even after we left the page or even closed the browser. We were unable to get HTML5 video to work at all.
[/size]
Sencha Touch Kitchen Sink
As you might expect from the preceding tests, most of the Sencha Touch Kitchen Sink work, [size=150]and the UI is smoother than the Galaxy Tab but it’s not a fantastic experience. The browser still has a long way to go accelerating CSS3 transforms.[/size]

The Motorola Xoom: Suggestions for the HTML5 App Developer
Any HTML5 app developer looking at the Xoom: wait for the inevitable patch(es).

We were excited about the first true Android operating system for tablets and had high hopes for a mobile browser that was as powerful as the platform. Sadly, [size=150]the Xoom and Honeycomb are a real disappointment. We found consistent and reproducible issues in CSS3 Animations and CSS3 Transitions among other things. We had issues where the browser either hung or crashed. Regular scrolling was slow or below full framerate. We had issues where media playback failed or performed incorrectly. [/size]At times it felt like we were using a preproduction device, but we bought our test device from a Verizon Wireless store.
[size=150]
And beyond the HTML5 features, there were many more mundane web rendering issues: form element borders disappearing unpredictably at various zoom resolutions, CSS border radii with flattened edges, the accelerometer object being upside-down, the virtual keyboard causing layout bugs etc. Hopefully the patches will come quickly.[/size]

Until Google and Motorola ship a patch to update the browser to production quality, don’t expect good results from the Motorola Xoom. We said it in the Galaxy Tab review, and we’ll say it again now: we’re still waiting for the first awesome Android tablet. Next week we’ll do a sneak peak at HTML5 features in the RIM BlackBerry Playbook — but we’ll give you a one word prequel: “awesomeness”.

Però dai la pagina android la scarica più velocemente

[TigerShark]

Sorry, Steve: iPhone 50 Percent Slower Than Android on Web


Android phones whisk users across the web in two-thirds the time that the iPhone takes, according to a study that compared the two top mobile OSes’ performance when downloading web pages.

The study, conducted by mobile-website–optimization company Blaze.io, involved more than 40,000 downloads of web pages belonging to the Fortune 1000 companies. The iPhone took 52 percent longer than Android to render full web pages. On average, Android phones took 2.1 seconds to render non–mobile-optimized web pages, while the iPhone took 3.2 seconds.

Android bested the iPhone on site-loading time a whopping 84 percent of the time.

The test included the Samsung Nexus S (Android 2.3), Samsung Galaxy S (Android 2.2), iPhone 4.3 and iPhone 4.2. Pages were loaded using a strong Wi-Fi connection, and each device loaded each Fortune 1000 website three times.

Oddly, the study found that the much-touted JavaScript improvements in the latest versions of Android and the iPhone had little real-world effect on these web pages.

“Our conclusion is that JavaScript performance doesn’t impact an average page load time,” the company wrote in the study. “Apparently, JavaScript is already so optimized that it doesn’t play a big role in the time it takes to load a page. It’s likely that rich AJAX applications benefit from these improvements, but users should not expect their casual web surfing to move faster.”

Both OSes clocked in nearly identical 2-second loading times for pages designed especially for mobile devices.

The company says the results surprised them.

We assumed that similar hardware specs and the same WebKit foundation would make iPhone and Android’s browsers perform equally. We assumed that a faster JavaScript engine equals a faster browser. We assumed that 3G would be way slower than WiFi, even under good conditions.
All of these assumptions have been proven wrong when we actually measured those scenarios. Without measuring, you don’t know when and where you need to optimize.

The Android-vs-iPhone-F1000-Paper includes more details on Blaze’s methodology and conclusions and will definitely be required reading for the ongoing battle between Android and iPhone fanatics.

http://www.wired.com... ... phone-web/

Problem?

Si, ma stai confrontando i telefoni TOP di ora con un terminale vecchio quasi un anno?
prova un po' a vedere i test di ipad 2 con il processore piu' lento che fa il culo a qualsiasi android esistente a, mentre mia madre succhia cazzi, oggi.
Ah, e sono test di anandtech, non certo del primo che passa.

[eglio]

Spoiler

Sorry, Steve: iPhone 50 Percent Slower Than Android on Web


Android phones whisk users across the web in two-thirds the time that the iPhone takes, according to a study that compared the two top mobile OSes’ performance when downloading web pages.

The study, conducted by mobile-website–optimization company Blaze.io, involved more than 40,000 downloads of web pages belonging to the Fortune 1000 companies. The iPhone took 52 percent longer than Android to render full web pages. On average, Android phones took 2.1 seconds to render non–mobile-optimized web pages, while the iPhone took 3.2 seconds.

Android bested the iPhone on site-loading time a whopping 84 percent of the time.

The test included the Samsung Nexus S (Android 2.3), Samsung Galaxy S (Android 2.2), iPhone 4.3 and iPhone 4.2. Pages were loaded using a strong Wi-Fi connection, and each device loaded each Fortune 1000 website three times.

Oddly, the study found that the much-touted JavaScript improvements in the latest versions of Android and the iPhone had little real-world effect on these web pages.

“Our conclusion is that JavaScript performance doesn’t impact an average page load time,” the company wrote in the study. “Apparently, JavaScript is already so optimized that it doesn’t play a big role in the time it takes to load a page. It’s likely that rich AJAX applications benefit from these improvements, but users should not expect their casual web surfing to move faster.”

Both OSes clocked in nearly identical 2-second loading times for pages designed especially for mobile devices.

The company says the results surprised them.

We assumed that similar hardware specs and the same WebKit foundation would make iPhone and Android’s browsers perform equally. We assumed that a faster JavaScript engine equals a faster browser. We assumed that 3G would be way slower than WiFi, even under good conditions.
All of these assumptions have been proven wrong when we actually measured those scenarios. Without measuring, you don’t know when and where you need to optimize.

The Android-vs-iPhone-F1000-Paper includes more details on Blaze’s methodology and conclusions and will definitely be required reading for the ongoing battle between Android and iPhone fanatics.

http://www.wired.com... ... phone-web/

Problem?

Debunked

Jim Dalrymple:

One of the biggest surprises the Blaze team found was that “despite significant JavaScript performance gains in the latest crapple iOS 4.3 release and Google Android 2.3 releases, these improvement made no measurable improvement on the actual page load times of the sites tested.”

There is a good reason for this. According to Blaze’s own documentation the “measurement itself was done using the custom apps which use the platform’s embedded browser. This means WebView (based on Chrome) for Android, and UIWebView (based on Safari) for iPhone.”

Right. The problem with Blaze’s entire study is that they didn’t test what they claimed to be testing. They used custom apps for iOS and Android, but claim the results show that Android’s browser is faster than iOS’s Mobile Safari. Instead, their results show that Android’s WebView control is faster than iOS’s UIWebView control. Mobile Safari is not just a thin wrapper around the system’s UIWebView control — it has its own caching system, its renderer uses asynchronous multithreading (UIWebView does not), and, as of iOS 4.3, Mobile Safari uses its own much faster JavaScript engine (“Nitro”).

That’s not to say it isn’t interesting that Android’s WebView for apps is faster than iOS’s UIWebView for apps, but it just isn’t true that these results are indicative of anything regarding Mobile Safari’s performance. It’s easy to see that Mobile Safari is faster than UIWebView — just run something like the SunSpider benchmark twice, once in Mobile Safari and once in any app from the App Store with a web content view. On my iPhone 4, Mobile Safari runs SunSpider almost three times as fast as an app using UIWebView.

These Blaze guys are either incompetent or dishonest attention seekers, given that they claim this, in an update to their report:

Some wonder whether the new Nitro JavaScript engine was used in our measurements. We’re still investigating this issue, as the report was completed before it was made known. So far we’ve seen indications in both directions, so we can’t say for sure it’s being applied.

That said, the results from measuring Android show that JavaScript only accounts for a small percentage of the total load time, about 15% on average. This implies that even if Nitro is not in use, it likely can only slightly narrow the gap. We’ll follow up with any additional info.

Because the thing is, Nitro isn’t the only difference Mobile Safari’s rendering and UIWebView’s rendering. Mobile Safari has better caching and asynchronous multithreading, too.

Non hanno testato il browser di iOS 4.2/4.3 vs il browser di Android 2.2/2.3, hanno testato WebView di Android vs UIWebView di iOS tramite una loro applicazione dedicata che si appoggiava a questi servizi
Non è la stessa cosa che testare i 2 browser

[Cyrano]

?[/url]":2vatekc6]

Spoiler

http://www.wired.com... ... phone-web/

Problem?

Debunked

Jim Dalrymple:

One of the biggest surprises the Blaze team found was that “despite significant JavaScript performance gains in the latest crapple iOS 4.3 release and Google Android 2.3 releases, these improvement made no measurable improvement on the actual page load times of the sites tested.”

There is a good reason for this. According to Blaze’s own documentation the “measurement itself was done using the custom apps which use the platform’s embedded browser. This means WebView (based on Chrome) for Android, and UIWebView (based on Safari) for iPhone.”

Right. The problem with Blaze’s entire study is that they didn’t test what they claimed to be testing. They used custom apps for iOS and Android, but claim the results show that Android’s browser is faster than iOS’s Mobile Safari. Instead, their results show that Android’s WebView control is faster than iOS’s UIWebView control. Mobile Safari is not just a thin wrapper around the system’s UIWebView control — it has its own caching system, its renderer uses asynchronous multithreading (UIWebView does not), and, as of iOS 4.3, Mobile Safari uses its own much faster JavaScript engine (“Nitro”).

That’s not to say it isn’t interesting that Android’s WebView for apps is faster than iOS’s UIWebView for apps, but it just isn’t true that these results are indicative of anything regarding Mobile Safari’s performance. It’s easy to see that Mobile Safari is faster than UIWebView — just run something like the SunSpider benchmark twice, once in Mobile Safari and once in any app from the App Store with a web content view. On my iPhone 4, Mobile Safari runs SunSpider almost three times as fast as an app using UIWebView.

These Blaze guys are either incompetent or dishonest attention seekers, given that they claim this, in an update to their report:

Some wonder whether the new Nitro JavaScript engine was used in our measurements. We’re still investigating this issue, as the report was completed before it was made known. So far we’ve seen indications in both directions, so we can’t say for sure it’s being applied.

That said, the results from measuring Android show that JavaScript only accounts for a small percentage of the total load time, about 15% on average. This implies that even if Nitro is not in use, it likely can only slightly narrow the gap. We’ll follow up with any additional info.

Because the thing is, Nitro isn’t the only difference Mobile Safari’s rendering and UIWebView’s rendering. Mobile Safari has better caching and asynchronous multithreading, too.

Non hanno testato il browser di iOS 4.2/4.3 vs il browser di Android 2.2/2.3, hanno testato WebView di Android vs UIWebView di iOS tramite una loro applicazione dedicata che si appoggiava a questi servizi
Non è la stessa cosa che testare i 2 browser

si vero , il test e' un po' farlocco...


C;.s;.s;.s;.;s.