> On Apr 1, 2015, at 16:32, Sergey Bylokhov <sergey.bylok...@oracle.com> wrote: > > Hi, Jim. > 31.03.15 0:00, Jim Graham wrote: >> Hi Sergey, >> >> Slow us down where? > Slowdown occurs before the images will be cached in the native texture. At > least two times: for the first time "image->conversion->window" blit and for > the second time "image->conversion->texture->window" blit. Plus we will get a > slow down when we cannot create a texture for some reason(big/unsupported > size, low vc memory on intel etc). > Simple image copy on my osx 10.10 retina(J2DBench 1000x1000 BufferedImage to > the screen): > argb_pre: num-reps="1268" > argb image: num-reps="539" > cached image: num-reps="10362" > > Not a big deal, but based on this I changed all image types in the swing to > eliminate these unnecessary conversions.
Sergey, do I understand this correctly, when I say, it seems that using the "wrong" image type there is a two time penalty, but once the image is cached (which happens, once we drew it), it will draw as quickly as any other VRAM-cached image? In other words: the gain of adjusting PNGDecoder to produce pre-multiplied images is probably minimal? Thanks, -hendrik
