These are chat archives for openseadragon/openseadragon

3rd
Nov 2016
John Hoffer
@thejohnhoffer
Nov 03 2016 00:58

Keep in mind that it takes a number of cycles to load all the tiles... you might need to make use of the _fullyLoaded flag

I'm not sure I understand. It takes multiple cycles to load all tiles within a given viewport? Okay - but I don't see how that affects my patch if I'm cancelling every call to updateViewport while the flag is set.

Are you worried about the flag getting set and unset with only half the tiles in the viewport loaded?
I've just made what I consider to be the basic changes needed for this to work. I'm about to build it and test it out in several ways for my use case.
John Hoffer
@thejohnhoffer
Nov 03 2016 01:56
I'll probably start testing it tommorrow- but I've documented my little PR here: openseadragon/openseadragon#1071
John Hoffer
@thejohnhoffer
Nov 03 2016 13:47
Related: world.needsDraw() == true even if the only tiledImages that need drawing are tiles with opacity == 0 that won't even load and certainly won't ever draw. Incidentily, this also holds for my new preload flag. If all the undrawn tiledImages have preload == true, then world.needsDraw() == trueeven though the only undrawn tiledImages are specifically set by the flag as not needing to be drawn, thank you very much.
John Hoffer
@thejohnhoffer
Nov 03 2016 14:40

At first I thought we'd want a world.canDraw method. Instead, I'd be happy with an exposed world.getItemsmethod that just returns world._items. That way I can loop through them and just filter them by preload and opacity as I please. Surely this has been called for before. Right now I need to basically do this:

items = [...Array(world.getItemCount()).keys()].map(world.getItemAt,world)

Where I instead mean this:

items = world.getItems()

Or, if I decide to be evil, this:

items = world._items
Ian Gilman
@iangilman
Nov 03 2016 16:36
@thejohnhoffer Yeah, when I mentioned the fullyLoaded flag, I was thinking that preload() would be a one shot thing, rather than a status. You'd want to consider the preload done after all the tiles have loaded. I'm happy with it being a status instead, though
needsDraw being true with opacity 0 (and preload false) seems like a bug that should be fixed... can you include that in the patch?
As for the opacity 0, preload true case, I agree it would be more efficient not to draw everyone else, but I think that implies a much bigger refactoring, so that we separate out the concepts of drawing versus loading a bit more. That could be something to follow on from #1020
...but I think for now it's fine to leave it as is
Ian Gilman
@iangilman
Nov 03 2016 16:42
Regarding exposing world._items via world.getItems(), I don't know that I have actually heard that request, but it seems like something someone would want. The current setup supports for loops, but not the other iterators.
My concern is just in protecting the developer from accidentally modifying the array, which is why we're not exposing it directly
One option would be to expose a world.eachItem() that you can pass an iterator into
Another option would be world.getItems() returning a copy of the array
John Hoffer
@thejohnhoffer
Nov 03 2016 20:01
Okay - I'm backburning the world.getItems() issue for now. I'll look at it agian once I finish this patch.
Ian Gilman
@iangilman
Nov 03 2016 20:02
Cool :)
Please let me know if that table meets your expectations. I also think I misunderstood what tiledImage._updateViewportdoes. As you had said, It seems that it triggers both the loading and drawing of the image. I had read your message too quickly and assumed it was only responsible for drawing.
updateViewport() is the top of the process and drawTiles() is the actual drawing
John Hoffer
@thejohnhoffer
Nov 03 2016 20:27
Ah- I read your comment on #1071 more carefully- I think I understand you now.
preload == true preload == false
opacity == 0 Load only Do Nothing
opacity > 0 Load & Draw Load & Draw
Ian Gilman
@iangilman
Nov 03 2016 20:28
Yes... just thinking it through myself now
I think what it comes down to is which option overrides the other... preload, or opacity 0
John Hoffer
@thejohnhoffer
Nov 03 2016 20:29
It seems like the only function of preload should be to override opacity zero...
Ian Gilman
@iangilman
Nov 03 2016 20:29
Funny how we were assuming it would work the opposite of each other... now I understand why you were going to call it preloadOnly
John Hoffer
@thejohnhoffer
Nov 03 2016 20:29
Yeah, I was thinking 'never draw' and you were thinking 'always load'
Ian Gilman
@iangilman
Nov 03 2016 20:30
Indeed
Well, if it's "never draw" then I think it definitely doesn't belong as a top level option
John Hoffer
@thejohnhoffer
Nov 03 2016 20:30
Haha- I thought about that too...
As documented, tiledImage.preload defaults to false, because it would be a very silly world if the default setting for our viewer were to not view the images.
Ian Gilman
@iangilman
Nov 03 2016 20:31
...and if it's "never draw" then preloadOnly makes a lot more sense than just preload
I'm trying to think if one or the other will be more pleasant to work with
I'm thinking maybe "never draw" is the more pleasant one, since you can get the effect you want by just toggling one flag
On the other hand, it feels a little odd to me that we would have two different ways of not drawing (opacity 0 and preloadOnly)
John Hoffer
@thejohnhoffer
Nov 03 2016 20:34
The reason would be due to the fact that opacity ==0doesn't load.
But yeah, neither option is the prettiest...
Ian Gilman
@iangilman
Nov 03 2016 20:35
Well, opacity 0 would load if we used "always load" for the meaning
I think the reason I was thinking "always load" is because it's more consistent with how the HTML5 video and audio elements work: http://www.w3schools.com/tags/att_video_preload.asp
John Hoffer
@thejohnhoffer
Nov 03 2016 20:36
RIght. I actually think "always load" is easier to understand.
Ian Gilman
@iangilman
Nov 03 2016 20:36
For that matter, when you're using a image preloader on a webpage, it doesn't preclude image drawing
well, what would you think about switching the logic to that?
John Hoffer
@thejohnhoffer
Nov 03 2016 20:38
I think that's better. It seems cleaner too. This way the preload flag literally only matters if you're in the business of setting opacity equal to zero.
Ian Gilman
@iangilman
Nov 03 2016 20:39
Okay, cool... good to talk it through... funny how we each come with our own preconceptions!
(and yeah, sorry I wasn't clear about the relationship between updateViewport and drawTiles... I meant the one called the other)
John Hoffer
@thejohnhoffer
Nov 03 2016 20:40
This would work really quite well for my use case too. I'm constantly toggling preloading of images that must stay hidden. When I want to unhide the image, I really don't want to worry about whether I accidentally leave the preload flag on.
Ian Gilman
@iangilman
Nov 03 2016 20:40
Yeah, makes sense
John Hoffer
@thejohnhoffer
Nov 03 2016 20:43
Alright- I feel pretty good about this. The funny thing is that it's currently not even documented that an opacity of zero prevents image loading and image drawing. I assume most would assume that images with opacity == 0 would not draw but still load. Judging by the code, that behavior must have been intentional-
Ian Gilman
@iangilman
Nov 03 2016 20:44
Yeah, but it was added a little later. Would you mind updating the docs to mention that fact?
(the opacity 0 fact, not the "added later" fact ;) )
John Hoffer
@thejohnhoffer
Nov 03 2016 20:48
Haha- Sure! A tiledImage with 0 opacity will neither load nor draw. needs to be said somewhere before I can say If tiledImage.preload is true, the tiledImage will load even if a 0 opacity prevents drawing.
Ian Gilman
@iangilman
Nov 03 2016 20:49
Indeed :)
John Hoffer
@thejohnhoffer
Nov 03 2016 20:57

I thought I would win with:

setPreload: function(preload) {
        this.preload = Boolean(preload);
        this._needsDraw = true;
},

But then I got my hands on a Boolean object (instead of a primative)... so after this:

var should_be_false = new Boolean(false)
myImage.setPreload(should_be_false)

I get this: myImage.getPreload() === true

Is it enough to do this:
setPreload: function(preload) {
        this.preload = true == preload;
        this._needsDraw = true;
},
Sorry - not worth bothering you with this... It's just javascript junk.. I'll go look for other examples in the code..
John Hoffer
@thejohnhoffer
Nov 03 2016 21:07
Thanks so much for your help!
Ian Gilman
@iangilman
Nov 03 2016 21:11
@thejohnhoffer I was wondering about the Boolean(preload)... good to know its pitfalls
I usually just use !!preload which does the job but isn't necessarily pretty or readable
preload ? true : false works
true == preload relies on the == coercion, whereas we try to generally === (I think)
... so it might be seen as a typo
John Hoffer
@thejohnhoffer
Nov 03 2016 21:14
It's actually the boolean object that causes problems.
!!(new Boolean(false)) === true
(new Boolean(false)? true: false) === true
The == coercion is the only thing that lets a false object be seen as false...
Ian Gilman
@iangilman
Nov 03 2016 21:16
Yup, but !! and ? also work
Anyway, I'm fine with any of them... I do agree that we shouldn't rely on the user passing a true Boolean
John Hoffer
@thejohnhoffer
Nov 03 2016 21:18
Just clarifying that what I mean by the above was that !! and ? don't work iff the user passes a javascript Boolean object itself created by new Boolean(false)
Ian Gilman
@iangilman
Nov 03 2016 21:19
Oh, I see. Weird
Well, is that something anyone ever does?
John Hoffer
@thejohnhoffer
Nov 03 2016 21:19
Only me...
Ian Gilman
@iangilman
Nov 03 2016 21:19
lol
Well, if the == supports all of the scenarios, let's go with it
John Hoffer
@thejohnhoffer
Nov 03 2016 21:20
Haha, okay. I'll show you really breifly how a dummy like me winds up with a Boolean object:
Ian Gilman
@iangilman
Nov 03 2016 21:20
I'd like parens around it... this.preload = (true == preload);
John Hoffer
@thejohnhoffer
Nov 03 2016 21:20
Sure - me too.
Ian Gilman
@iangilman
Nov 03 2016 21:21
(and I personally prefer preload == true because it feels more readable, but I understand the arguments for the reverse and don't feel strongly)
John Hoffer
@thejohnhoffer
Nov 03 2016 21:22
Someone got the idea in my head that 'functional programming' is the way to go so okay I write this mess (in my own code):
var setPreload = function(image){
     image.setPreload(this);
}
[image0,image1,image2].map(setPreload,false)
When you bind a primative like a boolean as the this context of a function, it gets unintentionally converted to a javascript boolean object because aparently function contexts must be objects.
I just found that out today - so I suppose this is a PSA ...
Ian Gilman
@iangilman
Nov 03 2016 21:25
Nice... that's what you get for being on the cutting edge! ;)
It would've never occurred to me to do that... I'm learning all sorts of new stuff today!
John Hoffer
@thejohnhoffer
Nov 03 2016 21:26
Yeah, I think a secret part of me must purposefully do this so I can't read my own code later...
Anyway, I'll keep working on the PR later tonight. Thanks for humoring me!
Ian Gilman
@iangilman
Nov 03 2016 21:28
lol
Sounds good... thanks for educating me!
Alexey Tikhonov
@altert
Nov 03 2016 21:40
@iangilman hello. I’m creating a PR for link to the cruiser photoalbum project. It reports - can’t automatically merge, does it mean I’m missing something?
for in the wild links
Ian Gilman
@iangilman
Nov 03 2016 21:42
@altert Hmm... did you get the latest master?
I'm not seeing it here https://github.com/openseadragon/site-build/pulls ... you're still working on it?
Alexey Tikhonov
@altert
Nov 03 2016 21:43
haven’t created it yet so as not to mess things up. checking
Ian Gilman
@iangilman
Nov 03 2016 21:46
Okay... well, if you've got the latest master from site-build I don't see why merging should be a problem.
Alexey Tikhonov
@altert
Nov 03 2016 21:46
oh oops I’ve missed latest master
Ian Gilman
@iangilman
Nov 03 2016 21:46
:)
Cool... looking forward to the patch!
(always fun to have new things in "In the Wild")
Alexey Tikhonov
@altert
Nov 03 2016 21:48
question on alphabetizing) The is not supposed to count, right?
‘the'
Ian Gilman
@iangilman
Nov 03 2016 21:48
Correct
Alexey Tikhonov
@altert
Nov 03 2016 22:00
yeah. it’s always interesting to know what people do with the stuff you create
Ian Gilman
@iangilman
Nov 03 2016 22:01
For sure, and OSD seems to get used for all sorts of really cool data!
Nobody wants to present a gigapixel image of their couch...
Alexey Tikhonov
@altert
Nov 03 2016 22:02
I’ve got so many plans for multimedia projects based on OSD.. too little time)
Ian Gilman
@iangilman
Nov 03 2016 22:03
Indeed indeed...
Well, I look forward to seeing all of them!
Alexey Tikhonov
@altert
Nov 03 2016 22:12
thanks. btw I’ve got a question regarding one of them
I’m thinking of adding secondary images (e.g. reverse of image) here
It’s multiimage, so I guess I can add them on the same positions with opacity=0
but if I want to make some kind of animation - rotating the image
I guess I can do it with OSD canvas transformations.
Ian Gilman
@iangilman
Nov 03 2016 22:16
So you want to be able to toggle between different views on the same "image", so you're going to stack them on top of each other and change the opacity for which one you want to be seen?
Alexey Tikhonov
@altert
Nov 03 2016 22:16
yes
Ian Gilman
@iangilman
Nov 03 2016 22:16
...and then when you switch between them you want some sort of transition?
Alexey Tikhonov
@altert
Nov 03 2016 22:16
yeah
Ian Gilman
@iangilman
Nov 03 2016 22:16
Well, fading is the easiest transition, of course
Alexey Tikhonov
@altert
Nov 03 2016 22:17
sure. fading I’ve already done for another project
Ian Gilman
@iangilman
Nov 03 2016 22:17
If you want to be able to rotate individual images, that's now landed on master, if you want to play with it
See #1006
Alexey Tikhonov
@altert
Nov 03 2016 22:17
oh interesting
Ian Gilman
@iangilman
Nov 03 2016 22:17
(I assume you want to rotate individual images, not the whole scene)
It's just 2d rotation... we don't have any support for flipping and whatnot
Which were you thinking?
Alexey Tikhonov
@altert
Nov 03 2016 22:18
individual. But I’m indeed talking about flipping. something like this http://rosphoto.org/collection-en/virtual-museum/film-stills-soviet-movies-in-advertising-photography/
I guess on flip start I’ll need to change opacity of underlying image so it will be drawn and then apply canvas transform, right?
Ian Gilman
@iangilman
Nov 03 2016 22:21
Cool... then yes, you'll need to add some sort of extra transformation after OSD renders. You can watch for update-viewport events; you'll get one after every canvas draw that OSD does; then you can warp it however you want
Alexey Tikhonov
@altert
Nov 03 2016 22:22
ok. thanks!
Ian Gilman
@iangilman
Nov 03 2016 22:22
Let me know how it goes... seems like an interesting technique!
Alexey Tikhonov
@altert
Nov 03 2016 22:23
sure. won’t be too soon probably. It’s still in early stage, and visual effect will be added last of course
Ian Gilman
@iangilman
Nov 03 2016 22:27
Of course :)