So I've just gotten my app to work on IE10/WP8 (demo here), and one thing I've noticed is that both scrolling and transitioning between carousel cards are reasonably sluggish on Windows Phone. Specifically, it takes like half a second for the screen to catch up to my finger. I'd say it's at about 80% of the responsiveness than I get from Android and iPhone, which both have pretty much perfect responsiveness. For reference, here are the devices I'm testing with:
iPhone 4
Android Kyocera Rise
WP8 Nokia Lumia 920
Desktop PC (Windows 8)
So among the phones, my Windows Phone is easily the most powerful, so it likely isn't just a hardware consideration. I've found this sluggishness in fastbook (http://fb.html5isready.com) as well. However, the sluggishness on either app does not exist on my Windows 8 PC.
Is there a particular consideration that needs to be taken with this part of performance in WP8? I've done quite a lot of work optimizing overall performance on the app (destroying/recycling all unused DOM elements, event delegation, etc) and the rest of the app runs quite well. So I'm not sure where I should go from here.
Thanks in advance!
How are you serving those large images? Have you tried using sencha.io to serve them? You can also use the yahoo tool smush.it to crush images further without loss of quality.
Another question: are you using CSS shadows and effects? These can have a noticeable performance hit sometimes...
Also the custom font, how are you implementing that? Google fonts work well, or are you implementing it another way?
:-)
Related
Right now I'm testing on an Iphone 5 and everytime I add hardware acceleration (translatez(0)) on an element it seems to dramatically increase the performance while I can't figure out anything negative.
What are the disadvantages of putting all elements into hardware accelerated mode?
I noticed some z-ordering issues between hardware- and non-hardware accelerated elements. What other disadvantages should I pay attention to?
How is this with other devices and browser, like Android or Windows Phone?
I guess the answer to this question will follow from the answer above, but why isn't everything harware accelerated by default?
I had 2 times a problem with the hardware acceleration.
First in Firefox, that just doesn't show radial gradients (on some computers).
And once in Android Webview, where I got one some devices flickering and slowdowns.
So, my experiences with hardware acceleration: it's sometime just more error-prone.
One common bug I have seen when enabling "hardware acceleration" for elements that might contain a lot of children or occupy big portion of the screen is that some browsers might not render it at all leaving you with big white spot in the middle of your screen.
I have seen this bug mostly as a result of optimization of a responsive web page, where everything works flawless on small screen and then it does not on desktop Windows with Chrome for instance. I think this depends on OS and graphics adapter, but I have never dig into it much more. The solution usually is to narrow down the usage of hardware acceleration just to the portions of DOM you really need to.
Im developing a html5 webApp for iPad and when I open it with Safari, this quit suddenly.
I'm using RoyalSlider plugin and I think the problem may be there since I'm using multiple instances but I don't know which is the specific problem and can´t solve it!
When I just use one instance there is no problem but I really need to use multiple instances of the slider.
Has anyone had similar problem?
When a browser crashes due to rendering content of a web page it is a browser bug. Even if the content is invalid the browser must handle that.
I have no idea about iPod and iPad and iGod stuff, but maybe also on those systems there is the possibility to launch the browser from the command line instead of clicking a button? This is usually the first step to take when trying to find out why some application crashes.
I have experienced crashing issues with iPad Safari and lots of large, hardware accelerated images, particularly on the first generation iPad. From a quick look at the Royal Slider homepage, it looks like they use hardware acceleration on iOS, though I don't know how they have it implemented.
When I encountered this problem it was because I was using a -webkit-transform: translate3d(0,0,0) effect to trick the iPad into hardware accelerating a div full of large images. The page would crash on load, but I was able to make it work by being more selective about which images I was trying to get the iPad to hardware accelerate at any given time. You might start by looking through the Royal Slider CSS to see how it's manipulating the images. Hope this helps!
Im currently working on a mobile web app and am wondering if I should use individual images or continue with using image sprites like I would for my desktop site? Im just worried about the increased file size from combining all the images and how this could have an effect on the load time of my pages?
Kyle
I don't see anything wrong with using a sprite set, just bear in mind that if you target the app for iPhones, they will only cache files under 25kB in size. So, if your image grows too much, it would, paradoxically, be a better idea to split it into separate images. This will account for more HTTP requests on the first run of the app - but will not generate the additional HTTP request continuously with each subsequent page load, saving both your and the iPhone user's bandwidth :). Oh, same applies for JavaScript and CSS files :).
Sprites work just fine on the vast majority of phones (barring older Nokia Series 40, BlackBerry pre v. 6.0 and any legacy devices (anything without a full HTML 4.01 browser).
What you should be aware of is that if you are using a flexible/responsive layout with primarily flexible units, it can be very hard to properly position the sprites while retaining the flexibility in the layout.
My apologies for a more "theoretical" question, though I suppose this is more of a "state-of-the-industry" question: I'm curious about the options available for building a website meant to target multiple platforms (desktop browsers + touchscreen devices, like tablets and smartphones).
Technologies like CSS3 Media Queries give us the ability to format our content based on screen size (among other things), which is great - but what about other functionality? For instance, touch events - these can still get very sticky depending on what device you're targeting, etc. So is it possible to build one site to target all of these platforms? Or is it still necessary/better to use device detection scripts to redirect to versions of the site meant for touchscreens (Apple-devices or otherwise)? Or perhaps, does it depend on what you want to do? Is there a line drawn that, once crossed, would require a separate version of a site to be made? Anyone care to share their experiences?
It all depends on how complex your website features will and and how they differentiate from the offline or online version.
Sometimes it's better to make a totally different version of your website and redirect to it, sometimes, a few touchevents calls on the page will not make any different for desktop users, while mobile will see something different.
One good case to look at is the WP-Touch plugin for Wordpress. While you have a version of wordpress for regular browsers, it tweaks PHP into delivering a totally different and mobile experience for the mobile user.
If you have the patience, resources and time to make a proper mobile website from your regular one, do it! If you don't, a different stylesheet and some touch events properly coded can seal the deal
I am considering a project in which workstations, connected to a central server display various content under the control of a central timeline.
Requirements are that the kiosks could have various compositions of monitor and an extended desktop. This screen space would be use to display images, movies or various mosaics of images and movies.
For example, a machine with 3x3 monitors might be configured to display video in the lowest right four screens, a title on the top three videos and whatnot elsewhere.
I am figuring out how to create the viewer. I think that sticking to web technologies I know well would be good and using JavaScript for the timeline engine sounds easy.
As for codecs and video drivers I think I would stick with Chrome, Css3 and Html5, I think I can require Chrome and Windows 7.
There are a few concerns, though.
Will there be performance problems considering video split on different monitors on an extended desktop?
Will it be pixel predictable to size and stack divs so that images fit inside a physical monitor or monitor group?
Thank you all.
A great solution for this is Adobe AIR. You are already talking about HTML, might as well check that out.
The nice thing is that AIR provides facilities for kiosks. Check out this link:
http://www.adobe.com/devnet/flex/articles/flex_kiosk.html
Just replace everything there that says Flex with HTML/Javascript. The platform functionality is available to both technologies.
As for stretching a browser or AIR app across multiple screens, I believe you would have to manually position the window yourself. I.e., if you maximize an app window on a multi-monitor setup, it expands to the size of the monitor only, not the entire viewable area. You likely will have to manually position/resize in Javascript.
As for using Chrome as a client, see this thread:
http://www.google.com/support/forum/p/Chrome/thread?tid=12bde481a208c4ca&hl=en
It doesn't look like Chrome supports a kiosk mode.
Browser shouldn't be a problem at all. Just remember the architecture - you'll need a server somewhere and each kiosk will be a client. Just set up a port/url for your app and there you go. Chrome has some features that allow you to prevent users from exiting the app. I forget the specifics, I believe it involves incognito mode and something
Company I work for does something a lot like this. We make 'apps' that run on iPad and another touch screen device called MSI (btw - one of the advantages here is the freedom of using different client platforms), but not in the typical Objective-C way. Theres a server with a LAMP stack and the client uses the browser.
Will there be performance problems considering video split on different monitors on an extended desktop?
I think more than multiple monitors what you really have is multiple clients. This is interactive to some degree right?
Will it be pixel predictable to size and stack divs so that images fit inside a physical monitor or monitor group?
Yes. I don't really do artsy design and display details so I can't comment on specifics. But I don't think this is too hard - especially if all the clients are similar. Majority of this would be dictated by CSS.
EDIT - took a look a what we do on chrome. between running on start up, using kiosk mode and incognito (both can be runtime flags) and the regular F11 kind of full screen, you should be pretty much there
Will there be performance problems considering video split on different monitors on an extended desktop?
IMHO screen space does take a little toll on your video processing. You will need a relatively good video card to support such huge amount of displays. I am a user of dual screen on ATI Radeon HD 5750 (1GB), and I can do intense gaming on my main screen while read news and be on twitter on my other screen.
Will it be pixel predictable to size and stack divs so that images fit inside a physical monitor or monitor group?
DIVs can be easily styled and positioned using CSS. You can define the number of pixels for both width and height. And if you do your storyboarding and layout design, everything should fit in your window.
However the trouble for you is that I assume you're stretching the browser window across the 3x3 screen. I recommend you to instead have one browser window per display.
I've tried that Chrome can full screen on each display without exiting-full-screen-mode on the others.