Interesting, I did not know that! 

On Tuesday, July 4, 2017 at 12:14:03 PM UTC+9, swiftcoder wrote:
>
> What platform are you on?
>
> On some platforms the native format is BGRA, *not* RGBA (this is a common 
> problem when porting between Mac and Windows, for example).
>
> On Mon, 3 Jul 2017 at 18:45 Benjamin Moran <[email protected] 
> <javascript:>> wrote:
>
>> 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] <javascript:>.
>> To post to this group, send email to [email protected] 
>> <javascript:>.
>> Visit this group at https://groups.google.com/group/pyglet-users.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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.

Reply via email to