I agree. As an embedded software developer, I noticed the same thing. The stereotypical geek culture is curiously absent. An investigation into why this is the case would be interesting.
Of course you can use framebuffer objects to draw into a texture. In fact, if I were to implement such a split solution (render textured quads with OpenGL for compositing the widgets, and use the CPU for drawing the widgets themselves), I would use FBOs. That still does not change the fact that drawing the widgets themselves remains unaccelerated.
That is another benefit, you are right. Don't underestimate the huge advantage it brings to the rendering engine, however. Anyway, I guess we can agree that QML is a good idea overall:)
I wish to elaborate on why the painter model is inefficient with today's GPUs.
The painter employs an imperative approach that does not allow for much freedom. Example: begin(), line(), text(), line(), end(). The two line() calls should be grouped together, but they cannot, because then the result would not be equal (what if text() drew over the first line, then the second line() call drew over the text for example?). The result is pretty bad: the underlying implementation has to perform tons of unnecessary shader switches (since font rendering most likely uses different shaders than the line drawing code), and perhaps texture switches (if texture-based AA is used). In addition, every time the painter is used, a vertex buffer has to be filled with vertex data. It cannot be easily cached. And this applies to *every* begin..end painter sequence.
A declarative QML-like approach is a much, much better idea. The fundamental reasons are that (1) the renderer now always has a global picture of what the frame shall look like, (2) intermediate results are much easier to cache, (3) no strict sequence of drawings is given, therefore the renderer is free to reorder and merge drawcalls in any way it wishes. This benefits even pure CPU-based rendering - the Enlightenment Foundation Libraries render using a graph, and are extremely efficient (they clip and cull primitives early on, group primitives together, IIRC can even detect accumulated opacity from several alpha blended layers..).
C++ QML bindings would likely consist of an API that can modify the graph. Either way, the painter-based approach is gone.
This is an imperfect solution which assumes that redrawing inside the window (which is the OpenGL texture) is done quickly enough. It also splits the system into two parts: the hardware-accelerated window compositing part and the unaccelerated drawing part.
Such techniques assume the presence of a GPU. Forget about abstracting that away with a painter-based architecture. The fundamental problem is that the painter acts at a level that is too low. This is the reason for the higher-level QML scenegraph. As for the missing C++ bindings, thats debatable, but if some appear one day, expect a high level API. Nothing else makes sense.
Intel drivers are infamous for overstating what they actually support. So you see "3.0" in the glxinfo output, and yet it does not implement it all. Last time I checked, even though the AMD drivers are much improved, they are still far behind the nVidia ones in terms of stability and bug-free OpenGL support.
I am not saying that I *like* nVidia's approach. But when I need up-to-date 3D graphics, I have no choice.
People need to make conscious decisions on what they purchase if the situation is going to improve. Many people are doing this already. Many more need to start doing it though..
If you want stable, hardware-acceleratd OpenGL 3 or 4 support, you buy nVidia cards. Since I work a lot with OpenGL 4 (and sometimes 3), I have no options. I had an ATI/AMD card once, and will never buy again. Anything beyond basic 2D is crappy with these (due to the awful drivers). Same goes for the Intel chipsets.
So, some of us do not have the luxury of picking our hardware based on ideologies. I am happy that I can use Linux at all for my projects..
Note that Boost is a collection of library, not one big one. For several of the libraries your bloat claims are true. This is the reason why I avoid Spirit, for example.
Some of the Boost libraries I use the most are: lexical_cast, optional, any, multi-index container, foreach (I tested out your problem, and didn't encounter it... but Boost 1.40 is very old, perhaps it was fixed), bind, function, noncopyable, format, pool, array, assign, bimap, iostreams, iterators, range, move, ref, thread, tuple. I haven't experienced significant bloat in the binary with most of them, and access boost arrays in inner loops for example, which I verify by looking at the disassembly. Now, iostreams has an overhead of course (the usual iostreams one, pulling in locales amongst others). Format is going to be slower than printf, but I don't use it in places where performance is critical.
My point is that you are throwing out the baby with the bathwater. Right tool for the right job, please. Boost is not a panacea, if you use Boost.Spirit for a binary that you are going to flash into an ARM926 platform with 100k of NAND flash, you are doing it wrong. As said before, I agree that some libraries are crap, other are excellent from a pure theoretical point but actually quite impractical (I am looking at Spirit again, and also on Proto, since it is rarely useful to non-library developers), others are useful for meta-programming, but you should not do that too often (Fusion, MPL, type traits, enable_if), otherwise you indeed get bloat. It is a fad right now to templatize everything in sight, yes, and this is in general a very bad idea. I worked with some people once who put EVERYTHING in the headers, with the result that compiling one.cpp file took several minutes on an i5, and consumed 2 GB RAM. The resulting object file was enormous.
As for your cmath problem, guess what, I experience similar issues with Qt. They define a "signals" macro, which then collides with variables called "signals". This is especially fun with signal processing software (I added a Qt GUI to one once). Similar issues exist with OpenGL headers and extension libraries etc. Furthermore, mixing cmath and math.h will cause problems, and you said. I use cmath in my code. Ditching cmath in favor of math.h is the wrong approach. The right one is to isolate the code that uses math.h.
Modern C++ makes it very difficult to produce buffer overflows. I wish people would stop criticizing C++ with age-old arguments that have been rendered obsolete long ago.
How the hell is Boost supposed to be slow? The term "slow" does not make sense. Which boost library are you *specificially* referring to? Same goes for Unicode. What does, say, boost.optional have to do with Unicode?
Some parts of boost are excellent, some are crap. Your comment reeks of ignorance. Some excellent libraries are: optional, bind, any, lexical_cast, multi-index container, graph (documentation is awful though), xpressive, shared_ptr, asio.
It means Civil Protection, duh. CP violation leads to pacification, citizen.
Re:so they are kinda like Muslims
on
How Doctors Die
·
· Score: 1
I think it depends. If it is a low-risk procedure with some tangible benefits, why not? However, if it is about getting a few years more out of your body, then I am inclined to agree. There was an epidose of Outer Limits (the 90s series) with a rich man who refused to die, and constantly underwent medical procedures to squeeze out a little more life. Eventually death itself came knocking to finish the job, feeling a little cheated.
Your point being? If I suffer excruciating pain, and tell my family to let me die, then I *am* making a choice how I want to die, am I not? Or are you confusing this with a DNR? The point of the DNR is to let you die in case you cannot choose anymore, for example because you are essentially braindead. But again, you make a choice.
You are right about virtual desktops, but wrong about the start menu.
When you use maximized application windows (which is how windows are used 90% of the time), you cannot access that nice floating menu anymore. You could turn one of the corners or edges of the screen in a zone where the menu always pops up, but what is the point of a context menu then?
In addition, the task bar shows you what's there: a start menu and the tasks. This is hidden in Windowmaker-style interfaces. Oh, and the taskbar is an efficient way of switching between tasks and having these tasks listed at the same time.
In addition, the start menu button is a fixed place, facilitating muscle memory. No matter what you are doing, you always know how to get access to the main desktop functionalities. You always have an "exit path", a way to regain control over the system.
Important things should always be visible and easily accessible. Main menu and the list of tasks are two such things.
So you would gladly return to the bulky and unwieldy handhelds from the '80s and '90s? 3 lbs are not decent. HANDhelds should not tire your arm. Besides, you are forgetting about power density here. More battery mass/volume does not automatically mean higher power density.
A WEB BROWSER THAT CAN NOT BE COMPILED IN 3 FUCKING GIGS OF RAM.
Indeed. This is totally insane. You'd expect some heavy-duty stuff like CGI rendering, finite element simulations, medical imaging (voxel grids), video authoring to be the kind of software that requires 64 bit. And then somebody mentions that we also need the 64 bit machine for building firefox.
Sheesh, I can even build an entire toolchain plus rootfs using something like OpenEmbedded on a 32 bit box, which gives me a complete system for an embedded device, plus user interfaces, video codecs, player software,...
The problem with electric cars has always been energy storage. This technology segment sucks overall, not just for electric cars. Just look at smartphones, laptops, tablets. Battery is always the problem.
Their range is enough for most commutes, which tend to be rather short. This is especially true inside major cities. I agree that batteries appear to be a dead end. I hope for breakthroughs in the supercapacitor segment. It also involves much fewer hazardous materials. But consider that the fuel cell is an overall game changer. The electrical engine is vastly superior to the ICE, energy storage has always been the actual problem of electric cars. But with the fuel cell, you can actually use existing gasoline as the energy source. This decouples the actual engine from the energy source; should other energy sources become viable, all that is needed is a different kind of fuel cell, or some new fancy supercapacitor etc. Right now, cars are pretty inflexible - when gasoline becomes overly expensive, you can throw away the engine, which often means throwing away the entire car.
Problems due to windows updates exist, and are next to impossible to fix on your own. You better hope Microsoft has a hotfix for that. At least, with Ubuntu, there is a chance somebody came up with a messy solution.
Well, in a matter of fact, if you drink PURE H2O (water only, no minerals, nothing else), then you will find out that the water actually is a poison.
I have never seen this rumor confirmed. The minerals in ordinary water are good for your body, but that does not mean their absence kills you. Over by drinking ONLY distilled water, over a long period, symptons of mineral deficiencies may occur, but that's about it.
Slashdot Mirror
I agree. As an embedded software developer, I noticed the same thing. The stereotypical geek culture is curiously absent. An investigation into why this is the case would be interesting.
I explained this here: http://linux.slashdot.org/comments.pl?sid=3019601&cid=40847477
Of course you can use framebuffer objects to draw into a texture. In fact, if I were to implement such a split solution (render textured quads with OpenGL for compositing the widgets, and use the CPU for drawing the widgets themselves), I would use FBOs. That still does not change the fact that drawing the widgets themselves remains unaccelerated.
That is another benefit, you are right. Don't underestimate the huge advantage it brings to the rendering engine, however. :)
Anyway, I guess we can agree that QML is a good idea overall
I wish to elaborate on why the painter model is inefficient with today's GPUs.
The painter employs an imperative approach that does not allow for much freedom. Example: begin(), line(), text(), line(), end(). The two line() calls should be grouped together, but they cannot, because then the result would not be equal (what if text() drew over the first line, then the second line() call drew over the text for example?). The result is pretty bad: the underlying implementation has to perform tons of unnecessary shader switches (since font rendering most likely uses different shaders than the line drawing code), and perhaps texture switches (if texture-based AA is used). In addition, every time the painter is used, a vertex buffer has to be filled with vertex data. It cannot be easily cached. And this applies to *every* begin..end painter sequence.
A declarative QML-like approach is a much, much better idea. The fundamental reasons are that (1) the renderer now always has a global picture of what the frame shall look like, (2) intermediate results are much easier to cache, (3) no strict sequence of drawings is given, therefore the renderer is free to reorder and merge drawcalls in any way it wishes. This benefits even pure CPU-based rendering - the Enlightenment Foundation Libraries render using a graph, and are extremely efficient (they clip and cull primitives early on, group primitives together, IIRC can even detect accumulated opacity from several alpha blended layers ..).
C++ QML bindings would likely consist of an API that can modify the graph. Either way, the painter-based approach is gone.
This is an imperfect solution which assumes that redrawing inside the window (which is the OpenGL texture) is done quickly enough. It also splits the system into two parts: the hardware-accelerated window compositing part and the unaccelerated drawing part.
More sophisticated solutions exist. Examples:
Using distance fields in OpenGL shaders for font rendering
Using textures for anti-aliased vector graphics rendering
Spline rendering in the GPU for non-affine vector graphics rendering (including text)
Such techniques assume the presence of a GPU. Forget about abstracting that away with a painter-based architecture. The fundamental problem is that the painter acts at a level that is too low. This is the reason for the higher-level QML scenegraph. As for the missing C++ bindings, thats debatable, but if some appear one day, expect a high level API. Nothing else makes sense.
It should be noted that the Enlightenment Foundation Libraries do something very similar with the combination of Evas and Edje.
Intel drivers are infamous for overstating what they actually support. So you see "3.0" in the glxinfo output, and yet it does not implement it all.
Last time I checked, even though the AMD drivers are much improved, they are still far behind the nVidia ones in terms of stability and bug-free OpenGL support.
I am not saying that I *like* nVidia's approach. But when I need up-to-date 3D graphics, I have no choice.
If he meant drivers with stable, usable OpenGL 3/4 support, then: only nVidia.
People need to make conscious decisions on what they purchase if the situation is going to improve. Many people are doing this already. Many more need to start doing it though..
If you want stable, hardware-acceleratd OpenGL 3 or 4 support, you buy nVidia cards. Since I work a lot with OpenGL 4 (and sometimes 3), I have no options. I had an ATI/AMD card once, and will never buy again. Anything beyond basic 2D is crappy with these (due to the awful drivers). Same goes for the Intel chipsets.
So, some of us do not have the luxury of picking our hardware based on ideologies. I am happy that I can use Linux at all for my projects..
Note that Boost is a collection of library, not one big one. For several of the libraries your bloat claims are true. This is the reason why I avoid Spirit, for example.
Some of the Boost libraries I use the most are: lexical_cast, optional, any, multi-index container, foreach (I tested out your problem, and didn't encounter it... but Boost 1.40 is very old, perhaps it was fixed), bind, function, noncopyable, format, pool, array, assign, bimap, iostreams, iterators, range, move, ref, thread, tuple.
I haven't experienced significant bloat in the binary with most of them, and access boost arrays in inner loops for example, which I verify by looking at the disassembly. Now, iostreams has an overhead of course (the usual iostreams one, pulling in locales amongst others). Format is going to be slower than printf, but I don't use it in places where performance is critical.
My point is that you are throwing out the baby with the bathwater. Right tool for the right job, please. Boost is not a panacea, if you use Boost.Spirit for a binary that you are going to flash into an ARM926 platform with 100k of NAND flash, you are doing it wrong. As said before, I agree that some libraries are crap, other are excellent from a pure theoretical point but actually quite impractical (I am looking at Spirit again, and also on Proto, since it is rarely useful to non-library developers), others are useful for meta-programming, but you should not do that too often (Fusion, MPL, type traits, enable_if), otherwise you indeed get bloat. It is a fad right now to templatize everything in sight, yes, and this is in general a very bad idea. I worked with some people once who put EVERYTHING in the headers, with the result that compiling one .cpp file took several minutes on an i5, and consumed 2 GB RAM. The resulting object file was enormous.
As for your cmath problem, guess what, I experience similar issues with Qt. They define a "signals" macro, which then collides with variables called "signals". This is especially fun with signal processing software (I added a Qt GUI to one once). Similar issues exist with OpenGL headers and extension libraries etc. Furthermore, mixing cmath and math.h will cause problems, and you said. I use cmath in my code. Ditching cmath in favor of math.h is the wrong approach. The right one is to isolate the code that uses math.h.
Modern C++ makes it very difficult to produce buffer overflows. I wish people would stop criticizing C++ with age-old arguments that have been rendered obsolete long ago.
What kind of comparison is this? ACE is something *completely* different. You are comparing apples to oranges.
How the hell is Boost supposed to be slow? The term "slow" does not make sense. Which boost library are you *specificially* referring to?
Same goes for Unicode. What does, say, boost.optional have to do with Unicode?
Some parts of boost are excellent, some are crap. Your comment reeks of ignorance.
Some excellent libraries are: optional, bind, any, lexical_cast, multi-index container, graph (documentation is awful though), xpressive, shared_ptr, asio.
Didn't you learn from Half-Life 2?
It means Civil Protection, duh.
CP violation leads to pacification, citizen.
I think it depends. If it is a low-risk procedure with some tangible benefits, why not? However, if it is about getting a few years more out of your body, then I am inclined to agree. There was an epidose of Outer Limits (the 90s series) with a rich man who refused to die, and constantly underwent medical procedures to squeeze out a little more life. Eventually death itself came knocking to finish the job, feeling a little cheated.
The Doctor tends to use different kinds of medicine. Stashed in a strange blue box.
Your point being? If I suffer excruciating pain, and tell my family to let me die, then I *am* making a choice how I want to die, am I not?
Or are you confusing this with a DNR? The point of the DNR is to let you die in case you cannot choose anymore, for example because you are essentially braindead. But again, you make a choice.
You are right about virtual desktops, but wrong about the start menu.
When you use maximized application windows (which is how windows are used 90% of the time), you cannot access that nice floating menu anymore. You could turn one of the corners or edges of the screen in a zone where the menu always pops up, but what is the point of a context menu then?
In addition, the task bar shows you what's there: a start menu and the tasks. This is hidden in Windowmaker-style interfaces. Oh, and the taskbar is an efficient way of switching between tasks and having these tasks listed at the same time.
In addition, the start menu button is a fixed place, facilitating muscle memory. No matter what you are doing, you always know how to get access to the main desktop functionalities. You always have an "exit path", a way to regain control over the system.
Important things should always be visible and easily accessible. Main menu and the list of tasks are two such things.
So you would gladly return to the bulky and unwieldy handhelds from the '80s and '90s? 3 lbs are not decent. HANDhelds should not tire your arm. Besides, you are forgetting about power density here. More battery mass/volume does not automatically mean higher power density.
But hey, here are some cellphones for you, manliest of men: http://www.lifelounge.com.au/resources/IMGTHUMB/Cell-clutch.jpg http://www.oaktreevintage.com/web_photos/Telephones/Radio-Shack_17-1003_Portable_Cell_Phone_Web.jpg
A WEB BROWSER THAT CAN NOT BE COMPILED IN 3 FUCKING GIGS OF RAM.
Indeed. This is totally insane. You'd expect some heavy-duty stuff like CGI rendering, finite element simulations, medical imaging (voxel grids), video authoring to be the kind of software that requires 64 bit. And then somebody mentions that we also need the 64 bit machine for building firefox.
Sheesh, I can even build an entire toolchain plus rootfs using something like OpenEmbedded on a 32 bit box, which gives me a complete system for an embedded device, plus user interfaces, video codecs, player software, ...
The problem with electric cars has always been energy storage. This technology segment sucks overall, not just for electric cars. Just look at smartphones, laptops, tablets. Battery is always the problem.
Their range is enough for most commutes, which tend to be rather short. This is especially true inside major cities.
I agree that batteries appear to be a dead end. I hope for breakthroughs in the supercapacitor segment. It also involves much fewer hazardous materials.
But consider that the fuel cell is an overall game changer. The electrical engine is vastly superior to the ICE, energy storage has always been the actual problem of electric cars. But with the fuel cell, you can actually use existing gasoline as the energy source. This decouples the actual engine from the energy source; should other energy sources become viable, all that is needed is a different kind of fuel cell, or some new fancy supercapacitor etc. Right now, cars are pretty inflexible - when gasoline becomes overly expensive, you can throw away the engine, which often means throwing away the entire car.
I tend to agree, however, keep in mind:
Silicon is abundant. Highly pure silicon is not. You need the latter for microchips.
Problems due to windows updates exist, and are next to impossible to fix on your own. You better hope Microsoft has a hotfix for that. At least, with Ubuntu, there is a chance somebody came up with a messy solution.
Well, in a matter of fact, if you drink PURE H2O (water only, no minerals, nothing else), then you will find out that the water actually is a poison.
I have never seen this rumor confirmed. The minerals in ordinary water are good for your body, but that does not mean their absence kills you. Over by drinking ONLY distilled water, over a long period, symptons of mineral deficiencies may occur, but that's about it.