It should be RGBA, the image has alpha, from the settings the format is
PNG-32 and Pixel format is RGBA8888. I did some tests since the texture
packer allows different types of formats.
I tried a POT texture, same result. NPOT texture, same result. The file was
an indexed PNG file (to save space and size), I tried unindexed with the
same result. I can't seem to not trigger this _convert findall function.
As far as code this is what I am doing.
#import xml.etree.ElementTree as ET
from lxml import etree as ET
import pyglet
class Atlas(object):
def __init__(self, filename, default=None):
tree = ET.parse(pyglet.resource.file(filename +".xml"))
self.xml = tree.getroot().findall("sprite")
self.imageFile = pyglet.resource.image(filename+".png")
self.defaultValue = self.getFile(default) if default else None
def getFile(self, name):
for sprite in self.xml:
if sprite.attrib['n'] == name:
region = self.imageFile.get_region(int(sprite.attrib['x']),
self.imageFile.height - int(sprite.attrib['y']) - int(sprite.attrib['h']),
int(sprite.attrib['w']), int(sprite.attrib['h']))
return region
return self.defaultValue
def load():
atlas1 = Atlas('image0')
atlas2 = Atlas('image1')
atlas3 = Atlas('image2')
atlas4 = Atlas('image3')
import cProfile
cProfile.run('load()', 'pyglet_load_test')
Basically the XML has data on the regions in the atlas where the actual
sprites are, then we extract them using getFile. However, just the loading
of it takes a while, and I'm only loading 4 atlases (in the above example)
On Sunday, July 2, 2017 at 11:42:56 PM UTC-5, Benjamin Moran wrote:
>
> Hey Charles,
>
> The internal format is RGBA, so you might start by seeing if your PNGs
> have an alpha channel or not. I took a quick glance at the module, and it
> might be possible to avoid the re.findall step altogether if the format is
> already the same.
>
> I'm not super familar with this module, but maybe the code can be
> rewritten to avoid using the `re` module altogether. It's not really doing
> very sophisticated matches anyway. This might be a nice project for someone
> to hack on.
>
> If you could post a small example snippet of what you're doing, I'll run
> it through vmprof and have a look at it as well.
>
>
> On Sunday, July 2, 2017 at 7:59:26 AM UTC+9, Charles wrote:
>>
>> I have been profiling my code lately trying to improve performance,
>> especially at startup. I am not too experienced with the ins and outs of
>> pyglet and image data in general, but after profiling it seems a big chunk
>> of time is spent on loading my large atlas files. They range anywhere from
>> 1024-2048 width or height.
>>
>> In my profiling it took 0.818 seconds on a Core i5 processor to load 5 of
>> them. I can only image how long it takes on a slower machine. After digging
>> deeper it seems a majority of the time is spent in pyglet.image._convert,
>> specifically the re.findall portion (over 90% of the time is spent on
>> that). Since I doubt we can improve the speed of a default library, I
>> looked at the comment where the findall is found and it says: "Pitch is
>> wider than pixel data, need to go row-by-row." which forces it to do a
>> findall.
>>
>> Is this because of my image format (PNG) or size? Would a different
>> format produce better results or a way around needing for it to findall?
>> Any input is appreciated, thanks.
>>
>
--
You received this message because you are subscribed to the Google Groups
"pyglet-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/pyglet-users.
For more options, visit https://groups.google.com/d/optout.
