Although not completely a programming related question, I need this information acquired to progress in the development of a game that is not run through the Oculus Rift, but rather run normally on as an application on the screen featuring the two "eye holes".
I have got the full release of Oculus, not one of the development kits. From what I've read and understood, these mirrored the screen by default, the full version does not. The full version from what I've heard instead uses its own driver for displaying graphics, not actually visible on the screen.
What I would like to do, is switch over so that I can see the screen through Oculus. How would one go about doing this?
Should you feel this question is not on topic under the Stack Overflow community, do tell where this should be posted. I do feel however that programmers are very right for the nature of this question.
What I would like to do, is switch over so that I can see the screen through Oculus. How would one go about doing this?
There are a number of applications that do things along these lines, including SteamVR, and Virtual Desktop, and Envelop VR.
From what I've read and understood, these mirrored the screen by default, the full version does not.
At no point has the Rift actually acted to mirror what's on screen. What you may be referring to is that previous development kits, when plugged in, would be visible to the operating system as just another monitor. However, anything that was on this monitor (windows, backgrounds, etc) was not actually usable, because the Rift display is divided in half, so each eye would see part of a distorted half of the screen. Completely unusable as a 'monitor replacement'.
Should you feel this question is not on topic under the Stack Overflow community, do tell where this should be posted.
Probably SuperUser, or alternatively a proposed VR specific stack exchange.
I do feel however that programmers are very right for the nature of this question.
Lots of questions are useful to software developers, but not specific to them. This site is for questions specific to software developers.
You want the Virtual Desktop app.
Related
I already used RecordRTC, but I had to abandon this decision, because I was getting videos with low quality and small fps. I tried change the options (videoBitsPerSecond, frameInterval) to improve quality, but nothing helped. Maybe I was not competent enough on this issue, but searches on this topic were futile.
If solution isn't exist, I'll look in universal plug-ins direction. Tell me what is better to use in a plugin to record a screen or region in good quality.
Presently only Firefox supports Screen Capture at navigator.mediaDevices.getUserMedia(). You can try testing various constraints at the Firefox implementation for screen, application, and window at getUserMedia Test Page.
I've been asked to make an interactive site map for a local development which has a few houses on it, so users can click on the relevant house within an aerial site layout, and see it's details listed, and whether or not it's sold.
Staff need to be able to mark houses as 'sold'.
It's been a while since I've done anything like this - in the past I would have used flash and had the sold status updated via actionscript and php, but things have moved on. What are some of the most popular methods now?
I've included an example below which is a lot larger scale than what I'm looking to do, but the same principle. I can't work out how they did it though, and I'd really like it to be vector so it can be zoomed into without losing quality, plus have the option to animate things like the popup bubbles etc if the tech allows.
Also, I'd probably be looking to include this in a Kirby CMS site, and hopefully have the updating done through that, but it's fairly flexible.
Thoughts appreciated!
https://www.redrow.co.uk/developments/the-sycamores-162433/interactive-site-map-4803v1
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I was having a discussion with a designer friend yesterday, the salient points of which I'll detail below:
2x images are larger files, but not the 4x you may think. In one example a 1x image file is 47kb & its 2x counterpart is only 55kb.
2x images are only for Retina screens, and despite being phased in on the desktop/laptop side, the truth is that most retina screens are mobile.
While wifi is becoming fairly ubiquitous, desktops (mostly 1x) are the only devices that never have to download data off a cell network.
These all led me to posit the question: Why are we spending energy on providing 2x images, when they are mostly accessed by mobile devices which have the greatest bandwidth limitations?
After sleeping on it, I started to wonder: well fine, if we're going to ignore that last issue, why not just only deal in 2x? CSS can handle scaling down the images in any case (perhaps I'm wrong here?) so why not save the media queries & save the effort to generate and store 2 copies of every image by just using 2x everywhere?
Am I crazy?
The file size issue does bother me. I think things should be as small as possible.
If you're not worried about that, though, the only, temporary issue I can think of is browser support for background-size. IE8 doesn't support it and it's still used enough to have to worry about it (at least on my projects). There's a polyfill for it, but it's not up to snuff with the real thing.
I think the answer depends on where you live in the world. Believe it or not, I live in an area with a lot of country roads that still only have dial-up. Sometimes, even that does not work. We are still not nearly as high-speed as we should be with desktops. I can't imagine them having to download that extra data when they view 1x.
So, I think it depends on your target audience, where they are more likely to live or what devices they use. We will get there in time, but for some, not yet.
Let analytics be your guide
I use the 5% rule. Once any feature is more than 2 standard deviations out of the norm, I drop support for it. In browserland, that means IE6 and IE7 are gone for me but I keep supporting IE8 because a size-able chunk of the audience is using that feature. Yeah the big guys like Google have dropped it but I still see a good chunk of traffic from it on a lot of sites. Why make them suffer?
Now how this relates to your question: ask yourself what percentage of your audience is on a 10Mbps+ LTE connection with retina screen. Maybe in your case it's 95% retina screens with LTE on mobile, but check your analytics package. My guess is that it's probably under 20%, in which case having fall-backs gives a better UX to 80% of your audience - easily worth the effort.
In my opinion I see those problems:
some older phone models (ex: iPhone 3G) and tablets (ex: iPad 1) have low memory. A big enough image can cause out of memory errors.
to scale an image the system has to load it at full size and do a complex scaling operation each time it draws it (sometimes it is cached).
a scaled down image doesn't look as good.
you can run into problems with them in older browsers (as mentioned by Bill Criswell)
it increases download size. If we consider a 10kb increase in size / picture * 10 pictures per page than you get 100kb per page load. If your page has to display a lot of images (think social), than the overhead is a lot.
you can improve your search engine rankings if your page loads faster and it is smaller.
The only major issue is file size. And as you state, in a lot of cases, the file size differences are minimal.
If we're talking mostly icons, the benefit is that a) icons aren't huge to begin with, so the file size increase is minimal and b) icons benefit the most from retina resolution.
On the other hand, if we're talking 'full screen' news photos, those could be quite a bit larger file-size-wise, but also look perfectly fine if they are not retina (as they are continuous tone) so there's a less compelling need to make those retina if you are targeting a mobile device.
A compromise for the latter might be to lazy-load them. Check the screen size. If phone-sized, load the regular image and call it good. If it's larger than phone size, load the regular image, then go back and grab the retina version for those on an iPad 3, for example.
The only technical problem is IE8 and older. They can't handle the CSS you'd typically use for retina images. There are workarounds, but not for sprites--which you'd commonly use for icons.
Eventually, we'll see more SVG support, which will solve this problem--at least for icons. When I am doing pure iOS work, for example, most all of my imagery is SVG now. It's smaller, and automatically retina-ready.
I'm working on a new web site that currently is configured as a full height (that is, 100% available browser window) application. In terms of layout, it is something like this - http://stevesanderson.github.com/fixed-height-layouts-demo/pane-transitions-tablet.html.
Our web site does nothing with the actual browser window size, like switch browser into full screen mode. It only uses the available space.
Operationally, this is going to be a semi-internal data entry application. Almost all pages are data entry forms or summary pages
Personally, I think makes a very nice looking app. However, some of the other developers are comparing this design with content in scrollable tags to be the same as iFrames. And as such should be avoided.
Is there any background / best practices information about designing a web site this way?
I personally love sites that choose to do this; I think that it's a great way to use up the available real-estate that you have. My one piece of advice would be to add a min-width and a min-height to your page so that you don't have to worry about your site breaking if the browser gets too small. This will not only improve the overall user experience, but will also prevent future headaches when trying to get your design to work in obscure dimensions.
It looks fine, and at first looks more like a 'real' app. The only weirdness with this sort of thing is that on OSX you get a bit of a bouncy effect when you hit the top and bottom because of the rubberbanding on the scroll. If you aren't sure what I mean, grab an iPhone/iPad/Mac and scroll up and down past the top or bottom of the content.
In reality it shouldn't be too hard to enable or disable this feature, so why not start with it, then revaluate once you have gotten going.
There aren't any good practices or background information that I know of on this subject. Just follow the normal rules of thumb, if it looks good, is light and loads well, and it is usable, why not?
Folks voting to close as not constructive, read the whole thing please. Specific questions at the end. Looking for real world examples and approaches.
Context
With numerous devices like smart-phones, tablets being used increasingly to access the web its important to plan, design (responsively) and develop (esp. your front end) to give the devices a fast and tailored user experience.
There's some amazing sites being built. Have a look at mediaqueri.es (resize your browser)
We see approaches such as
big screen first, then target smaller devices.
mobile first then media queries to spice things up for bigger screens.
device detection with different techniques (including server side)
and serving completely different markup and content to devices.
Question(s)
What are you folks doing out there today? Why did you choose your approach and most importantly if it isn't the most efficient approach to tackle this, then what is?
Things I'm looking for:
Is it a pure CSS / JS / HTML approach, or server side, or a combination - why?
Each device gets only the resources (images etc.) that it needs so it performs well
Maintenance of the site is easier, i.e. adding / changing features is not a huge pain
Some code samples are always useful
lets leave out old shitty browsers like ie7 and below
I think what you are looking for is Responsive Web Design.
See:
http://www.alistapart.com/articles/responsive-web-design/
http://coding.smashingmagazine.com/2011/01/12/guidelines-for-responsive-web-design/
Responsive Web Design (using CSS) does not necessarily address performance issues but is a good starting point. Keeping in mind that premature optimization is the root of all evil, you can profile your users and bandwidth and determine where you need to optimize once you have a working design in place.
For a discussion of some of the downsides, e.g., image resizing in the browser (you can work around this with CSS and/or AJAX, though), see:
http://www.webdesignshock.com/responsive-design-problems/
You will want to use a framework like PhoneGap. HTML evolves slowly but every day, about 10 new devices with new bugs "features" hit the market and you innocent app - there simply is no way for a small group of people to handle the necessary work.
As for different devices, there are two trouble areas:
Screen sizes
Render bugs
For screen sizes, there are pretty cool solutions today. For example, some frameworks add the CSS style "640x400" or "480x800" to the body element. That makes it dead simple to style elements depending on the screen size. Or you can use JavaScript pull in the matching style sheets.
For render bugs, you'll need workarounds. As I said above, this is nothing a single person or a small group can handle. Every few months, there is a new version of Android with a new render engine and new "features". You fix problems for one of them and break ten others at the same time. Select a framework which plays well with many devices and which is open to changes (read: avoid anything proprietary).
That way, you get solutions for the common problems and you can fix small issues yourself.
I would definately recomment RedFilters Answer (+1).
I just wanted to add some libraries which you might find interesting relating to this topic. They involve Browser feature detection & conditional resource loading.
check them out:
http://www.modernizr.com/
http://yepnopejs.com/