Claudius's dashboard

Claudius replied on October 08, 2009 22:38 to the question "How Do Scene & Viewport Work?" in OpenZoom:

I have not yet needed to set these values. They are, however, appearing in many other cases where i read them.

As far as i know, the longer side will be 16384 - the shorter side will be determined by the aspect ratio. I have not yet found out what's so special about this number, except for the fact that it's 2^14.

If you need to set the size of your image, try scale or zoom.

Claudius replied on September 16, 2009 19:57 to the question "How Do Scene & Viewport Work?" in OpenZoom:

I have been toying around with the container today. my findings include the following:
- sceneWidth, sceneHeight: The "virtual" size that is to be zoomed.
- width, height: set this to whatever suits your application, i usually set this to be the same size as my stage and leave x and y = 0.
- addding children to the container pins them onto the scene, which means they will be draggable, scale accodring to the container (add constraints and controllers to the container like you would add them to a MultiScaleImage).

There are Examples in the sdk/examples/ folder. The actionscript-folder contains a demo which uses the Container, Even if you don't have Flex Builder, the code might be useful for you.

Claudius replied on September 09, 2009 14:37 to the problem "Fix: setting new source, which is the same as the old source" in OpenZoom:

:-D Oops. you're right. Sorry 'bout that

Claudius replied on September 09, 2009 12:13 to the problem "Fix: setting new source, which is the same as the old source" in OpenZoom:

Hi,

I think, there may be a misunderstanding, I currently have an image, which is 4000x3000px in size, if I view it at what I consider to be 100% scale, the MultiScaleImage.scale property reads 0.249.. (see screenshot)

The image was converted with the deepzoom.py-library.

Claudius shared an idea in OpenZoom on September 09, 2009 11:01:

Property for Photoshop-like Zoom Level

I had the idea a while back, but haven't gotten around to implementing it yet. It's related to the "How to know when i reached 1:1 Scale or 100% zoom" questions.

If there was a getter (and possibly setter) for a photoshop-style zoomlevel, many of those questions were a lot easier. I think this kind of zoom is well-understood already and in some cases exactly what you need.

Claudius reported a problem in OpenZoom on September 09, 2009 10:40:

Fix: setting new source, which is the same as the old source

Hi there,

In a project we're doing, it may happen that the same MultiScaleImage.source is set again, the image disappears. I have made a small modification to MultiScaleImage, which I would like to share here in case anyone else runs into this problem.

In case you cant use the patch further down, just search for the lines
if (_source)
{
_source = null
container.removeChildAt(0)
viewport.showAll(true)
}

and move them down, AFTER THE BLOCK (not inside) of "if (value is String) {...}"

This patch alters the position of the removal of the "old" image in the container. Currently it is done before the equality-check. This leaves the user with a blank screen in case you set the same URL again.

diff MultiScaleImage.as.0.4.2 MultiScaleImage.as
142,148d141
< if (_source)
< {
< _source = null
< container.removeChildAt(0)
< viewport.showAll(true)
< }
<
151,152c144,146
< if (String(value) === url)
< return
---
> if (String(value) === url) {
> return;
> }
171a166,172
> if (_source)
> {
> _source = null
> container.removeChildAt(0)
> viewport.showAll(true)
> }
>

Claudius replied on September 02, 2009 14:04 to the idea "Extending FillConstraint" in OpenZoom:

I have been thinking about this, and would like to sign an adapted* SCA for openzoom. I can't think of reasons that might speak against it.

*) adapted in the sense that the Sun references in the SCA would have to be rewritten for OpenZoom.

Claudius asked a question in OpenZoom on September 02, 2009 14:01:

Performance Optimizations

Hi!

I am currently looking for places to improve performance. Profiling a simple project resulted in 80% of the processing time being spent on rendering.

I have optimized one or two functions, where typecasts were evitable, but this only accounted for less than a percent of performance.

Do you have any idea where i could optimize the project further?

Claudius replied on September 01, 2009 15:16 to the problem "Large Dimensions of MultiScaleImage's Parent DisplayObject" in OpenZoom:

Actually, no. I was just wondering why this happened.

This came up when we tried attaching the MSI to a self-resizing application. I was not sure which sprites' sizes to set, so i set all of them - which made the MSI tiny.

But in itself this is not currently a problem.

Claudius replied on August 31, 2009 07:57 to the idea "Extending FillConstraint" in OpenZoom:

I've read the agreement. If i understand it correctly, it grants you the possibility to change the license later, without asking the contributer's permission (since you already have it).

You are only bound to change to another FSF[1] or OSI[2] approved license. So it always stays open-source. In case you'd change it to something I don't like i could still fork the version before that and keep the "old" license.

I've looked over the articles. Now i am not familiar with many of those, but they all seem have the open source and freedom of use in common (a no-brainer, given who certified them ;-) ).

I'm sure this kind of discussion has already taken place in other projects. Maybe there are strong arguments to be found. I'll have a look for that in the next couple of days.

[1]: http://en.wikipedia.org/wiki/List_of_...
[2]: http://en.wikipedia.org/wiki/List_of_...

Claudius replied on August 31, 2009 07:07 to the idea "OpenZoom WordPress Plugin" in OpenZoom:

One thing that should be fairly easy would be a shortcode-plugin.

You'd have to do the image-processing on your PC and upload the files to a special folder. In your post or page you could write something like [openzoom image="test.xml"] which would then be replaced by the zoomer.

Of course, you could also do the image-processing on the server. The disadvantage here is: the plugin would be very hard to install. I also believe that shared-hosting environments would not be able to run it.

Claudius replied on August 28, 2009 22:24 to the idea "Order of Setting Transformer & Constraint Matters" in OpenZoom:

I can't really evaluate what's the better solution in this case. From a API-Standpoint it seems clearer, but on the other hand, i am still in the process of learning about openzoom and its internal workings.

If there is no dependency between transformer and constraint, this change might spare new users one or two moments of confusion.

I guess I'll be working with it for one or two days next week, maybe i'll dive deeper into the code.

Claudius replied on August 28, 2009 22:13 to the idea "Extending FillConstraint" in OpenZoom:

I'd be happy to share this under any license that openzoom is currently available with. (If this is of any help for your decision-making).

Claudius shared an idea in OpenZoom on August 28, 2009 08:02:

Extending FillConstraint

I extended the FillConstraint to also center the image in case it's zoomed out.

This here is tha patch for the changes i did. Maybe you find it useful.

Index: src/org/openzoom/flash/viewport/constraints/FillConstraint.as
===================================================================
--- src/org/openzoom/flash/viewport/constraints/FillConstraint.as (revision 8352)
+++ src/org/openzoom/flash/viewport/constraints/FillConstraint.as (working copy)
@@ -74,11 +74,17 @@
public function validate(transform:IViewportTransform,
target:IViewportTransform):IViewportTransform
{
- if (transform.width > 1)
+ var x:Number = transform.x
+ var y:Number = transform.y
+
+ if (transform.width >= 1) {
transform.width = 1
-
- if (transform.height > 1)
+ x = (1 - transform.width) * 0.5
+ }
+ if (transform.height >= 1) {
transform.height = 1
+ y = (1 - transform.height) * 0.5
+ }

return transform
}

This could also be an extended FillConstraint, but i did not see any advantage in moving the constrained image out of the container, so i altered FillConstraint.

Claudius replied on August 28, 2009 07:15 to the question "How Do I Calculate the Maximum Zoom?" in OpenZoom:

I think this is even easier:
I extracted this from the nano code and simplified it a little. I am not 100% sure that it is always right, but it was correct with everything i tested so far.

var limitingFactor:Number = Math.max(descriptor.width,descriptor.height);
var maxScale:Number = limitingFactor / Math.pow(2,14);

Very simple: you take the longer side, divide it by 2^14, there you go, that's your maxScale.

i do the calculatioen, when my multiscaleimage dispatches the Event.COMPLETE-Event.

Claudius replied on August 27, 2009 21:51 to the question "How do I stop twitter from shortening my urls?" in Twitter:

Hi Katrina, I am annoyed by this, too. I made this a "problem"-ticket stating two more flaws with shortening. Please add yourself to the "I have this problem, too" people or retweet it. http://getsatisfaction.com/twitter/to...

A comment on the question "auto-shorten urls?" in Twitter:

luisfhb, i rewrote this into a new ticket. If you're still interested in this topic, please add yourself to the "I have this problem, too".
The ticket can be found here: http://getsatisfaction.com/twitter/to... – Claudius, on August 27, 2009 21:49

Claudius replied on August 27, 2009 20:25 to the problem "Postage stamp size twitter pages" in Twitter:

Did you try your browser's zoom-level? In Firefox and Internet Explorer you can control your zoom with Ctrl + Mousewheel. They also have menu-option for resetting to "normal" zoom. In Firefox this is Ctrl + 0 (not sure what this is in IE or other browsers).

Claudius reported a problem in Twitter on August 27, 2009 20:07:

twitter should stop shortening my URLs

I wonder, why twitter shortens URLs at all?
(i know, this has already been asked, but hear me out)

In my opinion, there's no gain in shortening URLs. Sure, tweets are meant to be short and limited to 140 characters. But shortening the URL doesn't help here. Links are not shortened while you type them but after you already sent your tweet. This means, your link already fits into the 140-character limitation - why bother shortening it?

If I need to get a long tweet AND a link in there, I'll have to shorten the link manually - so shortening is really never helpful.

On the other hand, these urls are dangerous for three reasons:

• You don't see (immediately) where they lead. http://tr.im/my-short-link could lead anywhere from News to Porn.


• Shortening Services may one day shut down or change their url-scheme. You could never restore a link in this case [1].


• Shortening Services have been hacked before [2].

Twitter: Please give me an option to turn off shortening once and for all for my account. I don't want it, I think it's unnerving.
I also think it is a problem, so i marked it as one. If you think, shortening is a bad idea, retweet this with #stopshortening or add yourself to "I have this problem, too"

[1]: http://en.t37.net/trim-shutdow-and-sh... (okay, they did not shut down, but you get the idea.)
[2]: http://news.techworld.com/security/11...

Claudius shared an idea in OpenZoom on August 26, 2009 15:05:

Order of Setting Transformer & Constraint Matters

I just found out that it matters in which order you set transformer and constraint. From the outside (i.e. the API) there's no direct connection between the two, but looking at the code it's very simple to see.

function set constraint overwrites viewport.transformer.constraint
function set transformer overwrites viewport.transformer

So in case you first add the constraint and later on the transformer, you'll no longer have any constraints in place.

I have a patch (made from 0.4.2 SDK) for MultiScaleImageBase, which fixes this behaviour:

Index: MultiScaleImageBase.as
===================================================================
--- MultiScaleImageBase.as (revision 8310)
+++ MultiScaleImageBase.as (working copy)
@@ -186,8 +186,11 @@

public function set transformer(value:IViewportTransformer):void
{
- if (transformer !== value)
- viewport.transformer = value
+ if (transformer === value)
+ return;
+ var oldConstraint:IViewportConstraint = viewport.transformer.constraint;
+ viewport.transformer = value
+ viewport.transformer.constraint = oldConstraint;
}

//----------------------------------


Of course, it is debatable, if one should copy attributes from an old transformation to a new one, but i found it pretty confusing that the order, in which i set the attributes. matters.