Fps2D does not show any change when you turn on or off the setting on a GN.
On Jan 16, 11:09 pm, Zsolt Vasvari <zvasv...@gmail.com> wrote: > 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
