If you're going to refuse to use a web browser because they won't complicate their code base to satisfy an infinitesimally small number of users, I believe you'll find your solution here:
The opposite is true. If you put the tabs at the top of the screen, the user can just jerk his mouse upwards, and the top of the screen will limit movement, making it quicker/easier to get to the tab bar. If you put the tabs below the address bar, now you need a precise movement to get there. Either you're going to overshoot it and move the mouse back down, or you're going to move the mouse slower to get the precision to stop there.
For your first example, your browser isn't crashing, it's closing gracefully because you indicated to it that you do not need any tabs (or the browser). In what scenario would you need to keep the browser open without any tabs? If you have a single tab open and want to go to a different tab, you can do so. If you genuinely want a new tab in that scenario, CTRL-T, CTRL-TAB, CTRL-W. Yeah, not as convenient, but considering how rarely you'd want to do that anyhow, I'm not seeing a big issue.
For your second example, what's the point of showing http:/// in front of the URL when virtually all web traffic is going to be showing just that anyhow? Considering it's the primary protocol used, why not make it the default case, and make less commonly used protocols the special case that show the protocol in the URL to indicate that something different is going on? It saves space and lets me see more of the URL.
It's not so easy to do so. You're adding a ton of complexity with these kinds of things, because not only are you cluttering the options page with tiny little toggles, but you're causing a ton of extra code to try to handle the tab bar being in a different place, and you're breaking a whole bunch of assumptions all over the place (be it in code or themes) about where the tab bar is, what it is expected to look like, etc.
For example, Google has been working on an option for quite some time to move the tab bar to the side of the browser. It's been experimental for a long time, and last time I gave it a try, quite some time ago, it caused a whole load of problems. It's not a simple "flip a switch" kind of change. I can very much sympathize with the Chrome team if they don't want to undertake a whole lot of work to implement and support a new feature like this if they don't think many users would take advantage of it.
Speaking as a programmer, programmers are not designers. They should not, unless they have demonstrated an ability to do so, design UIs. Letting programmers design UIs is how we get software like emacs or vi: greatly productive for a small number of advanced users, completely unusable by almost any computer user apart from those.
Speaking as a Chrome user (and web developer), the ability to detach tabs is a critically important feature that I can't live without. The lack of said ability means that, when I need to view two tabs side-by side (often on different monitors), I have to open up a new browser and hope I can reproduce whatever was going on. It drives me nuts when I'm using a browser like IE, and am unable to do this. Even when I'm at home on my single monitor, and not working, I regularly tear off tabs and use the WIN+LEFT and WIN+RIGHT shortcuts to get them side-by-side...
I'm not sure how the feature works on Firefox, but on Chrome, there is no reason to add an option to disable this behaviour (and several reasons why not to add an option), as it's unlikely the user would do this by accident (having to click and drag a tab a decent distance to trigger it), the user can always simply not tear off tabs. Offering an option to disable it it would be like offering an option to disable tabbed browsing entirely; if you don't want to use tabs, just don't open any extra tabs.
But you could, if this technology is scaled up enough. A small 12"x12" display is limited in scope, but scale it up to an 84"x84" display, and then mount six of them orthogonally facing a single point, combined with a transparent motion-tracked conveyor system, and you've got yourself a pretty damned immersive 3D environment in which you can run around in.
Of course, a highly accurate motion tracking system that can determine how you should be moving relative to the ground while keeping you motionless is a pretty tall order itself. Essentially, the conveyor must accurately simulate inertia for a specific human body to make walking feel natural.
It sounds like they're just doing real-time holograms, though. Yeah, you can walk around it, but it still displays on a flat surface, it doesn't project an image in real space. Think of it like a big printed hologram, except you can update it in real-time. It's not a free-space display like Star Trek holograms.
Think of it this way: the Zebra display would be like looking through a window into a 3D world, but everything would have to be contained within the window.
I can still imagine some pretty neat ideas for future versions of the technology, however. Standing inside a cube with each face being a display surface, for example. 3D imagery in any any direction you care to look. Combine that with some sort of transparent conveyor belt system and you've got one half of a holodeck (the environment). Unfortunately, without free space display technology, you couldn't interact with anything; nothing could appear inside the cube.
I'm not sure we'll ever have practical free-space displays like that. There are various such displays available now (spinning projection surface, focusing lasers to create plasma balls in free space), but they all have limitations (enclosed vacuum for spinning projection surface, noise/temperature/lack of colour for plasma balls).
That was my first thought too, but the resolution just isn't there. These are VGA cameras, 640x480. All told, we're only talking about ~14 total megapixels, and that's only if you positioned each camera so that they didn't overlap and stitched the image together. The fixed focal length would make that impossible, though, you'd only really be able to do superresolution on 45 very similar images, which would probably net you one or two megapixels of effective resolution. In the end, even a hundred dollar point and shoot would do better.
It's all a matter of helping in bits. Optical IS gets you a bit, better sensors (higher usable ISO) helps, software algorithms that can compensate for motion helps, etc.
Most cameras already have MEMS gyroscopes onboard to do optical IS. The problem is that you can only compensate for so much by shifting the lens. If the camera recorded the motion data at sufficiently high resolution in the EXIF data, the postprocessing software could use this motion data to help guide the motion blur analysis.
It's not always possible to hold a camera steady. If you're moving in addition to the camera (either because you're following something, or because you're on a moving platform), or you have to use a slow shutter speed, etc.
There's also potential here for image stabilization in video. Software image stabilization for video can work wonders, but it generally can't compensate for motion blur. The result is that you get a steady image with motion blur going in different directions, which looks pretty odd. This is much more prevalent on tiny cameras that require slow shutter speeds, like cellphone video. If you can post-process your video, running each frame through this in an automated fashion, correcting the frames that have motionblur, you could at least significantly reduce the motionblur in those frames. The result would be a video that's both stable and doesn't suffer from strange motionblur artifacts despite a stable image.
And how do those textures get from the CPU to the GPU? Over the PCI bus. If you're doing a modern game, that's fine, but anything older that does software rendering is going to need to copy the entire frame over the bus.
Yep, this is exactly what my MythTV HTPC does, only using an older PCI card.
It takes practically zero CPU power to shovel bits
Case in point, my aforementioned HTPC is a Celeron (yes, a humble Celery) and plays all ATSC content (720p, 1080i) just fine.
VDPAU rocks. PCI does the job.
PCI is 133 MB/s. Shoveling 1080i60 to the GPU requires ~178 MB/s. Shoveling 720p30 to the GPU might work, as that only requires 79MB/s, but unless VDPAU does the entire process on the hardware (that is, you send nothing but the encoded stream to the videocard, and it handles the entire decode process end-to-end, including the scaling and overlay output), you're going to need at least two copies, so 720p is out too; PCI was half-duplex. I believe subtitles would require this sort of double-copy, even if VDPAU is end-to-end.
PCI was 133 MB/s, half duplex, while PCIe 1.0 1x would be 250MB/s full duplex. Any modern computer will have a few spare PCIe slots that you could use for that.
If it's an older machine, PCI will let you connect the monitors, but you can't even blit 1024x768 at 60hz over a PCI bus.
The PCI bus can do 133MB/s, half duplex. Your Dell 4550s are AGP 4x, which is 1066MB/s. A wee bit of a difference there. I doubt that you could do even 720p DXVA over the PCI bus, even blitting 720p at 60hz would require 158MB/s. So any device you tried to build with a PCI GPU, no matter how powerful, would probably be limited to standard def.
AGP might have some use, there's still some decent bandwidth there, 2133 MB/s.. But PCI? 133 MB per second? You can't even blit 1024x768 over a PCI bus at 60Hz. That's right, if you try to play 1993's Doom on a GeForce GT 520 over a PCI bus at 1024x768, you will be bandwidth limited below 60FPS. Doom. A game that was released on the Super Nintendo.
As for DXVA? I'm not sure if you've got enough bandwidth... DXVA normally still does some stages of the pipeline in software, which means copying the uncompressed frame from the GPU to the GPU at least once... Maybe 480p.
Indeed, it is. Opera is also available on the iPhone. And the blackberry. And featurephones. And Mac. And PC. And Linux. I'm not sure there's any computing platform that it's not available for...
It doesn't work because of the takedown request; it was not Apple or the porting developers who prevented distribution, but the complaining developer. As both the binaries and the source for the iPhone VLC port are still available, nothing has really changed except the scope of compatibility.
The source code to the VLC iPhone port is freely available available, the idea that the distribution of the binaries is more important than the distribution of the code is a bit backwards. Certainly the VLC team didn't think it was a problem, as they approved and aided in the port. Only one party objected, and he conveniently waited until after the work was done before objecting. He stifled an opensource project, firmly establishing himself as an enemy of opensource and consumer choice.
Apple were just keeping quiet about a GPL violation
In my opinion, there was no GPL violation. Since that aspect wasn't tested in court, it's only the opinion of the developer who made the claim to Apple, and Apple doesn't want to be put in the position to be liable for that. The argument was that the distribution terms of the App Store are incompatible with the GPL, but I disagree. If memory serves, the dispute was over the inability to freely distribute the content. However, since the content had no monetary cost, it was possible to freely distribute it by sending anyone the URL to access the content; the GPLv2 makes no provisions for the mechanism of distribution.
Intel's Atom and the Cortex A9 have about the same performance clock-for-clock (the A8 was a bit slower, the A9 is a bit faster). A single-core 1.6GHz Atom can, from personal experience, handle 720p h.264 content in software. Any dual-core Cortex A9 smartphone at 1GHz or above should be able to handle 720p30 h.264 video with the right codec. A dual-core A9 at higher clockspeeds (the SGS2 LTE and HD LTE are at 1.5GHz) can probably even do 1080p30 if you cut some corners (skip in-loop deblocking). Of course, there's little need for anything higher than 720p on a 4.5" display, unless you're plugging your phone into a larger display.
They're shipping some pretty sophisticated programmable GPUs in modern ARM SoCs these days, I wonder if there'd be any gains to be had by offloading some stages of the decoding pipeline in a software renderer to the GPU (in a purely shader-based fashion, since I don't think there are OpenCL interfaces for the SGX or Mali, and nVidia does't plan CUDA until the Tegra 3)?
Slashdot Mirror
If you're going to refuse to use a web browser because they won't complicate their code base to satisfy an infinitesimally small number of users, I believe you'll find your solution here:
http://gcc.gnu.org/
The opposite is true. If you put the tabs at the top of the screen, the user can just jerk his mouse upwards, and the top of the screen will limit movement, making it quicker/easier to get to the tab bar. If you put the tabs below the address bar, now you need a precise movement to get there. Either you're going to overshoot it and move the mouse back down, or you're going to move the mouse slower to get the precision to stop there.
For your first example, your browser isn't crashing, it's closing gracefully because you indicated to it that you do not need any tabs (or the browser). In what scenario would you need to keep the browser open without any tabs? If you have a single tab open and want to go to a different tab, you can do so. If you genuinely want a new tab in that scenario, CTRL-T, CTRL-TAB, CTRL-W. Yeah, not as convenient, but considering how rarely you'd want to do that anyhow, I'm not seeing a big issue.
For your second example, what's the point of showing http:/// in front of the URL when virtually all web traffic is going to be showing just that anyhow? Considering it's the primary protocol used, why not make it the default case, and make less commonly used protocols the special case that show the protocol in the URL to indicate that something different is going on? It saves space and lets me see more of the URL.
It's not so easy to do so. You're adding a ton of complexity with these kinds of things, because not only are you cluttering the options page with tiny little toggles, but you're causing a ton of extra code to try to handle the tab bar being in a different place, and you're breaking a whole bunch of assumptions all over the place (be it in code or themes) about where the tab bar is, what it is expected to look like, etc.
For example, Google has been working on an option for quite some time to move the tab bar to the side of the browser. It's been experimental for a long time, and last time I gave it a try, quite some time ago, it caused a whole load of problems. It's not a simple "flip a switch" kind of change. I can very much sympathize with the Chrome team if they don't want to undertake a whole lot of work to implement and support a new feature like this if they don't think many users would take advantage of it.
Speaking as a programmer, programmers are not designers. They should not, unless they have demonstrated an ability to do so, design UIs. Letting programmers design UIs is how we get software like emacs or vi: greatly productive for a small number of advanced users, completely unusable by almost any computer user apart from those.
Speaking as a Chrome user (and web developer), the ability to detach tabs is a critically important feature that I can't live without. The lack of said ability means that, when I need to view two tabs side-by side (often on different monitors), I have to open up a new browser and hope I can reproduce whatever was going on. It drives me nuts when I'm using a browser like IE, and am unable to do this. Even when I'm at home on my single monitor, and not working, I regularly tear off tabs and use the WIN+LEFT and WIN+RIGHT shortcuts to get them side-by-side...
I'm not sure how the feature works on Firefox, but on Chrome, there is no reason to add an option to disable this behaviour (and several reasons why not to add an option), as it's unlikely the user would do this by accident (having to click and drag a tab a decent distance to trigger it), the user can always simply not tear off tabs. Offering an option to disable it it would be like offering an option to disable tabbed browsing entirely; if you don't want to use tabs, just don't open any extra tabs.
But you could, if this technology is scaled up enough. A small 12"x12" display is limited in scope, but scale it up to an 84"x84" display, and then mount six of them orthogonally facing a single point, combined with a transparent motion-tracked conveyor system, and you've got yourself a pretty damned immersive 3D environment in which you can run around in.
Of course, a highly accurate motion tracking system that can determine how you should be moving relative to the ground while keeping you motionless is a pretty tall order itself. Essentially, the conveyor must accurately simulate inertia for a specific human body to make walking feel natural.
It sounds like they're just doing real-time holograms, though. Yeah, you can walk around it, but it still displays on a flat surface, it doesn't project an image in real space. Think of it like a big printed hologram, except you can update it in real-time. It's not a free-space display like Star Trek holograms.
Think of it this way: the Zebra display would be like looking through a window into a 3D world, but everything would have to be contained within the window.
I can still imagine some pretty neat ideas for future versions of the technology, however. Standing inside a cube with each face being a display surface, for example. 3D imagery in any any direction you care to look. Combine that with some sort of transparent conveyor belt system and you've got one half of a holodeck (the environment). Unfortunately, without free space display technology, you couldn't interact with anything; nothing could appear inside the cube.
I'm not sure we'll ever have practical free-space displays like that. There are various such displays available now (spinning projection surface, focusing lasers to create plasma balls in free space), but they all have limitations (enclosed vacuum for spinning projection surface, noise/temperature/lack of colour for plasma balls).
That was my first thought too, but the resolution just isn't there. These are VGA cameras, 640x480. All told, we're only talking about ~14 total megapixels, and that's only if you positioned each camera so that they didn't overlap and stitched the image together. The fixed focal length would make that impossible, though, you'd only really be able to do superresolution on 45 very similar images, which would probably net you one or two megapixels of effective resolution. In the end, even a hundred dollar point and shoot would do better.
It's all a matter of helping in bits. Optical IS gets you a bit, better sensors (higher usable ISO) helps, software algorithms that can compensate for motion helps, etc.
Most cameras already have MEMS gyroscopes onboard to do optical IS. The problem is that you can only compensate for so much by shifting the lens. If the camera recorded the motion data at sufficiently high resolution in the EXIF data, the postprocessing software could use this motion data to help guide the motion blur analysis.
It's not always possible to hold a camera steady. If you're moving in addition to the camera (either because you're following something, or because you're on a moving platform), or you have to use a slow shutter speed, etc.
There's also potential here for image stabilization in video. Software image stabilization for video can work wonders, but it generally can't compensate for motion blur. The result is that you get a steady image with motion blur going in different directions, which looks pretty odd. This is much more prevalent on tiny cameras that require slow shutter speeds, like cellphone video. If you can post-process your video, running each frame through this in an automated fashion, correcting the frames that have motionblur, you could at least significantly reduce the motionblur in those frames. The result would be a video that's both stable and doesn't suffer from strange motionblur artifacts despite a stable image.
(in this case, an incorrect focal plane)
This case involves motion blur, not incorrect focus.
Not all that far from the truth. About 90% of the population lives within 160km of the US border. The three territories make up 39% of the area of Canada, but only 0.3% of the population.
Not to be confused with CSIS, the Canadian Security Intelligence Service, our equivalent of the CIA.
And how do those textures get from the CPU to the GPU? Over the PCI bus. If you're doing a modern game, that's fine, but anything older that does software rendering is going to need to copy the entire frame over the bus.
Just grab the generic J2ME version, along with the java runtimes and the J2ME wrappers.
And subtitles? I understand there's a different surface used for that for VDPAU, though. DXVA, you'd be out of luck.
Opera Mini runs fine on Arm Linux.
Yep, this is exactly what my MythTV HTPC does, only using an older PCI card.
Case in point, my aforementioned HTPC is a Celeron (yes, a humble Celery) and plays all ATSC content (720p, 1080i) just fine.
VDPAU rocks. PCI does the job.
PCI is 133 MB/s. Shoveling 1080i60 to the GPU requires ~178 MB/s. Shoveling 720p30 to the GPU might work, as that only requires 79MB/s, but unless VDPAU does the entire process on the hardware (that is, you send nothing but the encoded stream to the videocard, and it handles the entire decode process end-to-end, including the scaling and overlay output), you're going to need at least two copies, so 720p is out too; PCI was half-duplex. I believe subtitles would require this sort of double-copy, even if VDPAU is end-to-end.
PCI was 133 MB/s, half duplex, while PCIe 1.0 1x would be 250MB/s full duplex. Any modern computer will have a few spare PCIe slots that you could use for that.
If it's an older machine, PCI will let you connect the monitors, but you can't even blit 1024x768 at 60hz over a PCI bus.
The PCI bus can do 133MB/s, half duplex. Your Dell 4550s are AGP 4x, which is 1066MB/s. A wee bit of a difference there. I doubt that you could do even 720p DXVA over the PCI bus, even blitting 720p at 60hz would require 158MB/s. So any device you tried to build with a PCI GPU, no matter how powerful, would probably be limited to standard def.
AGP might have some use, there's still some decent bandwidth there, 2133 MB/s.. But PCI? 133 MB per second? You can't even blit 1024x768 over a PCI bus at 60Hz. That's right, if you try to play 1993's Doom on a GeForce GT 520 over a PCI bus at 1024x768, you will be bandwidth limited below 60FPS. Doom. A game that was released on the Super Nintendo.
As for DXVA? I'm not sure if you've got enough bandwidth... DXVA normally still does some stages of the pipeline in software, which means copying the uncompressed frame from the GPU to the GPU at least once... Maybe 480p.
Indeed, it is. Opera is also available on the iPhone. And the blackberry. And featurephones. And Mac. And PC. And Linux. I'm not sure there's any computing platform that it's not available for...
It doesn't work because of the takedown request; it was not Apple or the porting developers who prevented distribution, but the complaining developer. As both the binaries and the source for the iPhone VLC port are still available, nothing has really changed except the scope of compatibility.
The source code to the VLC iPhone port is freely available available, the idea that the distribution of the binaries is more important than the distribution of the code is a bit backwards. Certainly the VLC team didn't think it was a problem, as they approved and aided in the port. Only one party objected, and he conveniently waited until after the work was done before objecting. He stifled an opensource project, firmly establishing himself as an enemy of opensource and consumer choice.
Apple were just keeping quiet about a GPL violation
In my opinion, there was no GPL violation. Since that aspect wasn't tested in court, it's only the opinion of the developer who made the claim to Apple, and Apple doesn't want to be put in the position to be liable for that. The argument was that the distribution terms of the App Store are incompatible with the GPL, but I disagree. If memory serves, the dispute was over the inability to freely distribute the content. However, since the content had no monetary cost, it was possible to freely distribute it by sending anyone the URL to access the content; the GPLv2 makes no provisions for the mechanism of distribution.
Intel's Atom and the Cortex A9 have about the same performance clock-for-clock (the A8 was a bit slower, the A9 is a bit faster). A single-core 1.6GHz Atom can, from personal experience, handle 720p h.264 content in software. Any dual-core Cortex A9 smartphone at 1GHz or above should be able to handle 720p30 h.264 video with the right codec. A dual-core A9 at higher clockspeeds (the SGS2 LTE and HD LTE are at 1.5GHz) can probably even do 1080p30 if you cut some corners (skip in-loop deblocking). Of course, there's little need for anything higher than 720p on a 4.5" display, unless you're plugging your phone into a larger display.
They're shipping some pretty sophisticated programmable GPUs in modern ARM SoCs these days, I wonder if there'd be any gains to be had by offloading some stages of the decoding pipeline in a software renderer to the GPU (in a purely shader-based fashion, since I don't think there are OpenCL interfaces for the SGX or Mali, and nVidia does't plan CUDA until the Tegra 3)?