These are chat archives for pixijs/pixi.js

1st
Jan 2016
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 00:33
@englercj englercj/resource-loader#39 - I know, that's brainfuck, but we need it :0
Chad Engler
@englercj
Jan 01 2016 00:46
Hmm, not sure about that. Resource objects are created as soon as you add something to the loader, and the image object is created as soon as you call load.
If you needed it before it loaded, you can access the data as soon as you call load
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 00:46
yes , and i need to create image object just for middleware in before() to run
so that middleware can create texture based on it
so middleware can ask loader to prepare image before loading starts
Chad Engler
@englercj
Jan 01 2016 00:48
Why do you need a texture before the resource loads?
What are you doing in a "before" middleware that can't be done in an "after" middleware in other words
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 00:51
pixijs/pixi.js#2269
no it cant be done in after middleware
Chad Engler
@englercj
Jan 01 2016 00:52
That doesn't answer my question
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 00:52
pixi-spine adds texture to loader as soon as atlas is ready and it needs that textures right now, not in async mode (page.rendererObject)
Chad Engler
@englercj
Jan 01 2016 00:52
Thats the confusing part
it needs that texture "right now"
why?
you can't do anything with it
There actually isn't a texture in the webgl sense
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 00:53
I can reference it as a texture, and that texture have a resolution
Chad Engler
@englercj
Jan 01 2016 00:53
but why can't you do that after it loads?
What happens if the loading fails?
How do you invalidate that texture object?
Now the user has to deal with multiple failure points?
I'm not sure what problem is being solved
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 00:55
right now everything is doubled
BaseTexture <-> AtlasPage
Texture <->. AtlasRegion
and there's that resolution variable that i hate
as about points of failure - there's only one point, if loader fails.
I just dont want to create copies of objects, for every TextureClass I need Option<TextureClass> which is not validated version of that thing
Chad Engler
@englercj
Jan 01 2016 00:57
My point is if you create the texture in before, then use that thing and just let the loader go off and do its own thing
then you have to come back and remove the texture if it fails
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 00:58
that's what im doing
Chad Engler
@englercj
Jan 01 2016 00:58
which is way more complex than never creating it in the first place if it doesn't load
Just answer me this: Why can't you wait until after loading to make the spine objects
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 00:59
previous version of pixi-spine used Texture.fromImage
Im trying to remove that
Chad Engler
@englercj
Jan 01 2016 00:59
Sounds like a good idea
requires you to change the logic to be async
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 01:00
but I have to create more stub classes that just "textures that arent loaded yet, but we know their resolution and stuff"
Chad Engler
@englercj
Jan 01 2016 01:00
why
is the question
not what
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 01:01
because that way code will be more readable, and I'll be able to delete big number of lines
and unnecessary classes
Chad Engler
@englercj
Jan 01 2016 01:02
I don't think making a hack in the loader to making seem sync when it isn't is a good idea
If you want to use the async loader instead of the sync methods
thats awesome
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 01:02
BaseTexture already works like a Promise<Image>
Chad Engler
@englercj
Jan 01 2016 01:02
but you need to change your code to work async
unfortunately
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 01:02
its already async
but it has some problems in architecture - every class is doubled
I want to use BaseTexture instead of some surrogate
Chad Engler
@englercj
Jan 01 2016 01:03
I'm saying there shouldn't be anythingh
nothing should exist
until you are ready to use it
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 01:04
BaseTexture.fromImage is not just legacy, its good async way of doing things, I just want to add it in the loader, its about 2-3 modified lines of code
Chad Engler
@englercj
Jan 01 2016 01:05
Its a sync way of doing things
it lets you use the texture synchronously
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 01:05
its not sync when its a promise
Chad Engler
@englercj
Jan 01 2016 01:05
its not a promise
it doesn't resolve
it doesn't reject
it just builds
and then works eventually
that is not what the loader is
the loader is a preloader
it loads resources and lets you use them
It is a different way of thinking about loading
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 01:06
ok, so I can actually use "Resource" object instead of BaseTexture there
Chad Engler
@englercj
Jan 01 2016 01:07
you could
but I don't recommend it
the problem is you haven't given me any reason why you need any object before it is done loading
just don't mjake anything until the load completes
at all
whats wrong with that?
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 01:08
ok, i'll give you line numbers
Chad Engler
@englercj
Jan 01 2016 01:08
I think you are misunderstanding me
if you want to use an async loader
rewrite your code to use an async loader
don't hack an async loader into your sync code
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 01:10
ok, problem: sync loader doesnt have async middlewares
and in some cases sync loader helps because I need Promise<Image> which is our current BaseTexture
Chad Engler
@englercj
Jan 01 2016 01:11
then rewrite to use the async loader :)
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 01:12
why cant I use promises, why do I have to add listeners myself every time?
Chad Engler
@englercj
Jan 01 2016 01:12
I don't follow
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 01:12
do you know what Promise is?
Chad Engler
@englercj
Jan 01 2016 01:12
obviously
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 01:13
Resource is basically a promise but its promise of resource, not promise of texture. I dont want to fill it with stuff like resolution
Chad Engler
@englercj
Jan 01 2016 01:13
You are not hearing me at all
you get to pick one
sync code, using "promises"
or async code
mixing them together is super confusing
to be clear, BaseTexture is not a promise
it is the representation of a source object to draw
it is an event emitter
but it is not a promise
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 01:15
it has a backend , which is Image or Canvas or my CompressedImage, and it has validation already
Chad Engler
@englercj
Jan 01 2016 01:15
right
so if you need that information right now
and not after loading
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 01:15
and AtlasPage from spine is the same thing
Chad Engler
@englercj
Jan 01 2016 01:15
then you need a synchronous-acting loader API
e.g. fromImage
if you can rewrite the code to not need that information up front, but need it only after loading is complete
then you need an asynchronous loader API
e.g. resource-loader
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 01:17
ok, so you just tell me that I have to double all classes that have some kind of loading
Chad Engler
@englercj
Jan 01 2016 01:17
I don't understand how you got from A to B
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 01:17
because i cant have BaseTexture before Im ready, I have to use my own AtlasPage
Chad Engler
@englercj
Jan 01 2016 01:17
why
dop
do
you
need
it
before
it
is
done
loading
That is the only thing that will resolve this discussion
and you can't tell me lol
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 01:18
Ok, sorry, 4:18AM and now i understand
hm
Chad Engler
@englercj
Jan 01 2016 01:18
you can either need it before it is loaded (sync) or not (async)
sounds like you already have sync (fromImage)
and you want async (loader)
so you need to rearchetect how your lib works
architect
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 01:19
I can actually do all that stuff after pages are loaded. which will be a big problem with current implementation. That means I cant parse atlas before images are loaded
Chad Engler
@englercj
Jan 01 2016 01:19
you can parse after each resource loads individually
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 01:19
so i'll need to parse it two times
Chad Engler
@englercj
Jan 01 2016 01:20
???
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 01:20
one to determine which files i need
second to actually create all objects
Chad Engler
@englercj
Jan 01 2016 01:20
the files you need determine the objects to create
make middleware for the objects you would load
that create the objects you will need
parse the atlas, load the proper resources potentially with metadata saying what object to create
then create them
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 01:21
ok
so what about sync loader then?
you absolutely sure that "sync" loader has to die?
Chad Engler
@englercj
Jan 01 2016 01:22
If I had my way I would kill it
but it is useful
so it will likely survive
in a plugin
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 01:23
but that way I wont be able to use sync loader in plugins, it wont be useful for me
Chad Engler
@englercj
Jan 01 2016 01:23
why not?
plugins can require other plugins
for sure
hopefully that makes sense?
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 01:26
async loader has queue and middlewares
Chad Engler
@englercj
Jan 01 2016 01:26
yeah ITS AWESOME
:D
I'm hoping to find a way in v3
v4*
to mix them
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 01:26
but sync loader is basically the same, it just returns some objects before they are actually ready
Chad Engler
@englercj
Jan 01 2016 01:26
I'll keep it in mind thaqt sync is useful
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 01:28
But to use sync loader in atlases, we have to either make separate sync/async loaders
either create BaseTexture before its backend (Image,CompressedImage, some other thing) finished the load process)
Chad Engler
@englercj
Jan 01 2016 01:29
to use the object sync
you need to create it before the backend loads
thats correct
thats why fromImage works for you
I'm saying in v4 I'm wondering how can this all be completely different from the way it is now and serve both use cases?
I don't know that it is possible
but I'm thinking about it
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 01:30
its useful because some info I know even before object loads, and I can have just one pass over text data, and not create middle "metadata" that will be used just to create objects later
Chad Engler
@englercj
Jan 01 2016 01:31
that same text can be the metadata
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 01:31
well, when load() is already called and loader is in "loading everything even if someone adds more" mode
Chad Engler
@englercj
Jan 01 2016 01:31
but I understand what you are saying
but I would argue that the information you are referring to is only useful if the load completes
if it doesn't you wasted time and memory created useless objects
which is why the preloader is superior
because you only create the objects post load
and it loads asynchronously
and has hooks for every step along the way
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 01:33
you need it mostly to detect failures
Chad Engler
@englercj
Jan 01 2016 01:33
if you architect your code also be lazy and work that way
it is magically delicious
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 01:34
BaseTexture is lazy, and it has resolution, and I want to set resolution before object loads so other middlewares can notice that and do something special about it
Chad Engler
@englercj
Jan 01 2016 01:34
thats why the texture parser loads first
middlewares are serial
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 01:34
yep
Chad Engler
@englercj
Jan 01 2016 01:34
you can rely on other middleware loading first
so when the textureParser runs
it will set that stuff
or can
you can make a middleware that does nothing but set the resolution
then another that uses it later
still no need to create the objects before they are needed
but it does require the lib to be written in such a way to wait
not on a bunch of promise objects
but just when the loader says "done" all the objects are created, loaded, and ready for use
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 01:36
yeah but it will look horrible.
Chad Engler
@englercj
Jan 01 2016 01:36
Thats subjective and I disagree
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 01:36
yeah, its subjective
but everything separates into lightweight objects and HORROR
Chad Engler
@englercj
Jan 01 2016 01:37
I'm honestly not sure what you mean
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 01:37
lightweight objects like textures and basetextures and HORROR like actual textures
imagine that im doing some tests without actual rendering
Chad Engler
@englercj
Jan 01 2016 01:37
if you make some gists of things you dislike about the loader
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 01:37
on server-side
Chad Engler
@englercj
Jan 01 2016 01:38
then sounds like you want to create a base texture, not load a resource
anyway I have to go
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 01:38
ok, thank you :)
I'm happy that you was there
Chad Engler
@englercj
Jan 01 2016 01:38
you can do new BaseTexture(new Image()) and move right along for tests
you can mock the loader
etc
mock the image loading
is the easiest
anyway
got to go
peace
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 01:39
please consider taking that PR :)
with it we'll be able to actually wire fromImage through your loader
and use middlewares
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 01:54
ok, that thing needs work. definitely
Ivan Popelyshev
@ivanpopelyshev
Jan 01 2016 02:00
closed PR-s, will re-work it tomorrow