Thanks for the code Charles,
If I read it correctly, we can distill it down to something like this for
benchmarking:
import pyglet
imageFile = pyglet.resource.image(filename)
def load():
# with different x, y, w, h values:
atlas1 = imageFile.get_region(x, y, w, h)
atlas2 = imageFile.get_region(x, y, w, h)
atlas3 = imageFile.get_region(x, y, w, h)
atlas4 = imageFile.get_region(x, y, w, h)
Since you tested all of the possible formats, and at least the RGBA one
should be OK, maybe the _convert method is unavoidable. We'll have to dig
in a little more.
On Tuesday, July 4, 2017 at 7:29:27 AM UTC+9, Charles wrote:
>
> 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.
