MIDI Kinetics Forum

So maybe it's just me, but does the example in the Canvas Learning Pack actually display a shadow for anyone else?

I've tried adjusting various parameters to try and make it more apparent, but nothing seems to make a difference.

Nope, dont work here either....havent yet tested with Lemur app 5.0.3 though (released somewhen yesterday)

Ahhhh . . . thanks for confirming.

I think this one slipped under the radar because frankly, what's the point of supporting shadows with no sane or practical way to implement (programmable) z-order either within or without the canvas object? Not a whole lot really.

Unless rendering the already-awful Tahoma font less readable is the goal!

Seriously . .
z-order is easily programmable both within and without the Canvas - both sanely and practically . . .
Within - it depends on the structure of your code . ..
Without - the usual bring to front /send to back . . .

I am pretty sure that 'faked' shadows could be used in the meantime if absolutely needed . . .
And if you hate the font so much then you could always just design your own in Canvas . . .

Shadows indeed stopped working, that slipped under our radar. Will be fixed in 5.1

Heh, no worries Nick.

Just trying to work out if Macciza's taking the pish or if he really, genuinely misses the point so completely and so often .

The z-order is fixed in Lemur at compile time and cannot be addressed programatically. You can build a working dynamic z-index easily enough of course . . . if you don't care about completely tanking the framerate and thus any semblance of usability (as it requires either massive duplication of objects or reliance on aliases, which can prove sketchy).

The possibility does exist to fake one up within Canvas also . . . but again, fake - as Canvas is a decidedly 2D paint-on-paint affair as it currently stands.

None of it sane or practical.

Sorry Joe

I guess sometimes I do miss the point of some of your comments . . . Perhaps I am misinterpreting your meaning, intent or both, at times . . .

Yes shadows aren't working - I did various tests and came to that conclusion, maybe sent a report to support, as I have for other issues.
Basically I accepted what I got and figured it will be added at some point, and if I really needed shadows currently (i.e. analog meter) I'd do without or fake it . . .
But has 'supporting shadows' got anything to do with 'z-order' ? Not really in my mind .. Or the font??

The HTML5 Canvas concept is a 2D context - in browsers and with Javascript various libs offer non-standard pseudo 3D environs or webGl gets used - but the Canvas is 2D. .
There may be libs that offer z-order but I don't think the standard Canvas does, it is up to you - I figure similar workarounds could be done with Lemur if I need them, but I ain't gonna complain. ..
Yes there is no obvious exposed z-order system for native Lemur objects, though again it can be programmed in some way depending on complexity wanted and how well it suits Lemurs paradigm
So I guess I just offer my opinion and view on these things - some things are just how they are, for various reasons, and I cannot change that so I come up with solutions/limits within those boundaries .
others are unexpected response and if I confirm and duplicate it I send it to support. There have been several that I have I sent in re Canvas support etc that are never mentioned on the Forum

So sorry for any misunderstandings, in either direction, its the nature of the net unfortunately.
And we simply have different approaches to dealing with those other issues, its all good . . .

Cheers
MM

Joe Soap wrote:Heh, no worries Nick.

Just trying to work out if Macciza's taking the pish or if he really, genuinely misses the point so completely and so often .

The z-order is fixed in Lemur at compile time and cannot be addressed programatically. You can build a working dynamic z-index easily enough of course . . . if you don't care about completely tanking the framerate and thus any semblance of usability (as it requires either massive duplication of objects or reliance on aliases, which can prove sketchy).

The possibility does exist to fake one up within Canvas also . . . but again, fake - as Canvas is a decidedly 2D paint-on-paint affair as it currently stands.

None of it sane or practical.

Outside of Canvas-specific topics (I haven't played with it yet), I adjust the 'stacking' of my objects by editing the .jzml file and ordering them manually with cut and paste. After that, I use the show(object, 0/1) command to bring things in and out as needed. I have a large button that simply fills the screen and does nothing that I use as a background to cover up objects if I want to draw attention to only a dialog box or other object in isolation.

The simplistic 'bring to front'/'send to back' options in the editor could be augmented with 'move back'/'move forward' like Photoshop and other applications do when they deal with layers. Although, based on a quick scan of templates in the user library, it doesn't appear that a lot of folks have made heavy use of layers in their templates, so maybe it's a very low priority.

[quote="Macciza"]
But has 'supporting shadows' got anything to do with 'z-order' ? Not really in my mind .. Or the font??

MM[/quote]

Well . . . in the universe in which I reside, z-order and casting shadows are more than tangentially linked. Basic physics.

And without support for dynamic z-order, perhaps an obvious use for supporting shadows would be to make Tahoma even uglier and less readable? Not that this would be exclusive to Tahoma - shadows on fonts are an attrocious idea regardless.