Holy macaroni!!!! What a thread.
Let's take an anology: First vehicle: A bicycle. You can go reasonably fast with it by the power of a single human. Second vehicle: A Ferrari with a fifth wheel powered by a pedal. Which one is faster? The point is, the Ferrari has 10,000x times the horsepower of human powered bicycle, but if you are not using it correctly, you still end up going slower. On Jan 17, 10:22 am, Kristopher Micinski <krismicin...@gmail.com> wrote: > On Mon, Jan 16, 2012 at 6:57 PM, sblantipodi > > > > > > <perini.dav...@dpsoftware.org> wrote: > >> I am not avoiding anything but you have failed to far to provide me > >> with something I could use to find such a flaw and fix it. > > > I have provided you three lines of code that works bad as the other > > primitives. > > >> Me neither, but you could be bandwidth limited for instance. Again, > >> the CPU has nothing to do with performance of the GPU so this > >> discussion is really not helpful. If your performance in software is > >> good enough, there is no point in drawing a comparison with other > >> devices that also run in software. > > > Bandwidth? Have you ever thought on how much bandwidth have a feature > > phone? > > Why the software runs better on gingerbread? > > Sincerely I'm not satisfied with the performance I get on CPU neither > > because I can > > do better with other OS. > > Talking about CPU performance the software runs far better on Galaxy > > Note (Gingerbread 1280x800) > > than on Galaxy Nexus (ICS 1280x720). > > Why? > > >> This piece of code is exactly what I was talking about in previous > >> message. Sending 640 rendering instructions to the GPU is extremely > >> expensive. The CPU will perform a lot better at this. Changing this > >> loop to a single drawLines() will likely fix the issue. > > > A feature phone is able to do it, gingerbread is able to do it, > > why ICS do it slow? > > You know that that was only an example, in real life drawLine can't > > be > > replaced with drawLines at least not always. > > >> Again, the problem is that a GPU performs very differently from a CPU. > >> Batching rendering operations is one of the best optimizations you can > >> do when running on the GPU. > > >> > In any case on the android documentation (API Level 11) I finded that > >> > drawLines() doesn't support antialiasing: > >> >http://developer.android.com/guide/topics/graphics/hardware-accel.html > >> > why do you call this a bug? > > >> This documentation is out of date. Antialiasing is supported with > >> drawLine() and drawLines() as of API level 12 or 13. > > > Are you really asking to drop Level 11 support or double the code to > > draw some lines? > > Maybe it's not true, but I think that it seems to me (and I suspect > many others on this list), that you fundamentally lack an > understanding of the differences between CPUs and GPUs. > > For example, parallelizing the previous bit of code will *obviously* > be better on a GPU because of the dispatch than multiple instances of > drawLine(), and this isn't a point that make the perf bad: it's just > bad coding. > > At *worst* you could argue that the compiler should somehow optimize > this to a drawLines call and do some fancy loop transformation based > on what it would know about the semantics of those functions and the > trade offs you were willing to make. But the example you make seems a > lot like a novice saying "Android is slow, I'm reading a megabyte file > and it's taking a few hundred milliseconds" when they're doing > multiple calls to read one byte... > > kris- Hide quoted text - > > - Show quoted text - -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
