Camelia, the Perl 6 bug

IRC log for #cdk, 2010-09-13

| Channels | #cdk index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
03:19 azeem_ joined #cdk
03:23 azeem left #cdk
03:48 sneumann joined #cdk
03:57 sneumann left #cdk
05:06 egonw joined #cdk
05:28 sneumann joined #cdk
06:08 jbrefort joined #cdk
06:13 egonw left #cdk
07:01 Gpox joined #cdk
07:06 mgerlich joined #cdk
07:28 mgerlich left #cdk
07:30 egonw joined #cdk
07:31 s_wolf joined #cdk
07:37 egonw left #cdk
08:27 mgerlich joined #cdk
08:44 s9asad joined #cdk
08:44 egonw joined #cdk
08:53 mgerlich left #cdk
09:03 jbrefort left #cdk
09:05 s_wolf left #cdk
09:06 mgerlich joined #cdk
09:07 s_wolf joined #cdk
10:50 asad_ joined #cdk
10:52 s9asad left #cdk
10:52 asad_ is now known as s9asad
11:26 s9asad left #cdk
11:27 s9asad joined #cdk
11:29 mgerlich left #cdk
11:31 maclean joined #cdk
11:32 maclean 'lo
11:34 mgerlich joined #cdk
11:37 mgerlich left #cdk
11:41 s9asad left #cdk
11:44 mgerlich joined #cdk
11:46 egonw hi maclean
11:46 maclean hi egonw
11:46 egonw maclean: so, in your last code example...
11:46 egonw everything is rendered in world coordinates
11:46 egonw and the zoom is 100% with affine transformation?
11:46 maclean Well, I would describe it like this:
11:47 maclean 1) Atoms and bonds (etc) are converted to TextBoxes and LineElements in scaled space
11:47 egonw :(
11:47 maclean 2) These scaled objects are drawn using a transformed graphics that has zoom
11:48 maclean basically the 'scale' is a kind of irrelevant thing.
11:48 maclean it just transforms different models to a consistent size.
11:49 maclean So, lets say ChemistryToolkitX makes 2D diagrams where atoms are 100 units (pm?) apart
11:49 egonw well, given a zoom=100%, the scale+margin ensures proper conversion of world to screen coordinates, such that it nicely fits the rendering window
11:50 maclean given a zoom of 100%, the scale fits any molecule into some rectangular space.
11:50 maclean I was using screenwidth/10
11:51 maclean sorry, min(screenwidth/10, screenheight/10)
11:51 maclean It's easier to understand with concrete examples, like these A-B "molecules".
11:53 maclean When the world distance between A and B is 10 (unitless), the scale might be 25. When the world distance is 100, the scale might be 2.5.
11:53 maclean And then the distance on screen is 250.
11:54 mgerlich left #cdk
11:54 egonw right
11:55 maclean So, if you want some platform-independent way to specify sizes, it will be to do with determining what proportion of the screen(?) to scale to.
11:56 maclean The user should NOT be specifying the scale directly, as this is a quite artificial thing.
11:56 egonw yes
11:57 maclean A number has to come from somewhere - I don't care where - but something like : min(windowWidth, windowHeight).
11:57 mgerlich joined #cdk
11:57 maclean Then something like a percentage of this can be specified.
11:59 maclean So if you are making images on your iPhone, maybe you want to make the percentage scaleFactor smaller(?) then for your giant flatscreen TV.
11:59 egonw yeah, sounds good...
11:59 egonw so, this scale factor is not an affine transformation right now?
12:00 egonw why not?
12:00 maclean see blog post #1 :)
12:00 maclean It affects the size of the font.
12:01 maclean So, your molecule laid out with distances of 100 between atoms will have tiny letters.
12:01 egonw URL again?
12:01 maclean mom
12:01 egonw I tried to follow your points, but found that difficult... I will read it again
12:01 maclean http://gilleain.blogspot.com/‚Äč2010/09/scaling-and-text.html
12:02 maclean It is difficult to follow because it is difficult :)
12:02 maclean Also, explaining without diagrams is hard.
12:02 egonw nah, still don't understand what the 'cost' refers too...
12:03 maclean changing the molecule model
12:03 maclean or, storing transformed coords, and constantly updating them
12:05 egonw no, that's not what I meant...
12:05 egonw why not have the scale as part of the affine transformation?
12:06 egonw that comes at some cost, your write
12:06 egonw what is *that* cost?
12:06 maclean Tiny fonts!
12:07 maclean Or huge fonts.
12:07 egonw why is that?
12:07 egonw so, font's are not scale with affine transformation?
12:07 maclean In the toy? Yes, but not the whole transform.
12:07 maclean See 1) and 2) above...
12:08 maclean Currently, there is this transform : moveToOrigin * scale * zoom * moveToScreenDraw
12:09 maclean I am splitting this into a bit that transforms the model (moveToOrigin * scale) and a bit that goes in the Graphics object (zoom * moveToScreenDraw)
12:10 maclean Only the second part, therefore, applies to the font.
12:10 egonw moveToOrigin * scale * zoom * moveToScreenDraw -> those are affine transformation settings, or in the rendering code?
12:11 egonw moveToOrigin * scale * zoom * moveToScreenDraw -> those are affine transformation settings, or in the generators?
12:12 maclean (moveToOrigin * scale) happens in the generators at the moment and (zoom * moveToScreenDraw) happens in the Visitor called by the renderer.
12:13 maclean but it could all happen in the visitor if necessary, it's just that only the second one can be applied to the Graphics.
12:15 maclean Or, for SWT, GC.setTransform(...)
12:15 egonw indeed... like with ZoomingDrawVisitor(Graphics2D, double scale, double zoom, double cX, double cY):
12:15 egonw g.scale(scale, scale)
12:16 egonw g.scale(zoom, zoom)
12:16 maclean yes
12:16 egonw or if we add the margin too:
12:16 egonw g.scale(scale*(1-margin), scale*(1-margin))
12:16 maclean Ah..no, no. "g.scale(scale, scale)" - not this ! no no !
12:17 maclean This is the point - not to transform the graphics with the 'scale'.
12:18 maclean We can call it something different, if that makes it easier - perhaps this is the source of my/everyone's confusion.
12:18 egonw why not?
12:18 egonw actually... it should be something like:
12:18 maclean It is a floating point number which we use to convert between some particular world coordinates and a consistent screen space.
12:19 egonw g.scale((zoom/100)*scale*(1-margin), (zoom/100)*scale*(1-margin))
12:19 egonw g.scale((zoom/100.0)*scale*(1-(margin/100.0)), (zoom/100.0)*scale*(1-(margin/100.0)))
12:19 maclean Yes that will fail horribly, for the exact reasons I have been outlining, correct.
12:20 egonw it will fail because g.scale() does not scale the fonts?
12:20 maclean No, because it WILL scale the fonts. In some arbitrary way that we don't want.
12:20 maclean For some input files, you will get tiny fonts, for others, huge fonts.
12:21 egonw please elaborate... why do some files randonmly get tiny of huge fonts?
12:22 maclean Ethene, for example might have 2D coords at [(100, 100), (300, 100)] or it might be [(1, 1), (3, 1)]
12:22 maclean It depends how the file is made.
12:22 egonw yes, so we have scale 1.0 and 100.0 (for a screen size of say 350x350 pixels
12:22 egonw )
12:22 maclean Right, yes.
12:22 maclean So the font will be also scaled by 1 or 100!
12:23 egonw yes, but that's what you want not?
12:23 maclean We _only_ want to multiply (scale) the font by the zoom, or by whatever factor the user chooses.
12:23 egonw of you have more pixels, you need a large font to fill those pixels
12:24 egonw let's say the label height is 0.5 bond length
12:24 egonw so, if the bond length in world coords is 1.5 (angstrom or so)
12:24 egonw then the font height should be 0.75 (angstrom or so)
12:25 maclean that's a very small font - and I'm not even trying to make a joke.
12:25 egonw which is then scaled to about (scale=100) 75 pixels height
12:25 egonw yes, in world coordinates it is...
12:25 egonw but not on screen
12:25 maclean font heights don't make sense in world coords.
12:27 maclean Look, you're welcome to try it out in the toyrenderer code, and see what happens.
12:27 maclean I have already done this, and seen how much it does not work.
12:28 maclean The approach I describe, however, _does_ work. It's not as nice in some ways, but still. Working is good.
12:29 egonw I'm not trying to convince you that you are doing it wrong...
12:29 egonw I'm just trying to understand why a other approach does not work...
12:29 maclean I know, I know.
12:29 egonw and whether it should work
12:30 maclean Well, one thing that is nice is dual-panels can work.
12:30 egonw and whether to forget about Java2D all together...
12:30 egonw and just render SVG and convert that to an image or so...
12:31 egonw have you consider this option:
12:31 maclean Actually, we use less Java2D in the current approach. That's why fonts are so screwed, because we are managing their sizes.
12:32 maclean s/:/?/ ?
12:32 egonw yeah, that's what I would prefer, not having to worry about sizes...
12:32 egonw have you consider this option:
12:32 egonw not using drawString()
12:32 egonw ah, no, never mind...
12:32 egonw that won't work
12:32 maclean But converting fonts to shapes? :)
12:32 maclean Yes, I've considered that.
12:32 egonw that's another thought I had too...
12:32 egonw but not what I was just thinking...
12:33 maclean ?
12:35 maclean Okay, anyway - I can summarise all this by saying : there seems to be a solution (try running client.MainFrame).
12:35 maclean It needs to be tested in various use-cases (SWT, AWTScrolling, etc) but is promising.
12:35 egonw I will experiment this week...
12:35 maclean ok
12:36 maclean I need to get some lunch.
12:36 maclean afk
12:37 egonw same here
12:49 maclean left #cdk
13:00 maclean joined #cdk
13:44 maclean Hehehe. public IMolecule makeMolecule(IBond.Order...orders);
13:44 maclean makeMolecule(SINGLE, SINGLE, DOUBLE, SINGLE);
13:46 egonw left #cdk
14:02 s9asad joined #cdk
14:13 mgerlich left #cdk
14:13 sneumann_ joined #cdk
14:13 swolf_ joined #cdk
14:13 s_wolf left #cdk
14:13 sneumann left #cdk
14:15 s9asad left #cdk
14:25 mgerlich joined #cdk
14:31 s9asad joined #cdk
14:35 bag__ joined #cdk
14:56 sneumann_ left #cdk
15:01 bag__ left #cdk
15:04 bag__ joined #cdk
15:17 bag__ left #cdk
15:40 s9asad left #cdk
15:41 s9asad joined #cdk
15:48 bag__ joined #cdk
16:07 s9asad left #cdk
16:15 bag__ left #cdk
16:28 maclean left #cdk
16:35 sneumann_ joined #cdk
16:41 jbrefort joined #cdk
16:59 swolf_ left #cdk
16:59 swolf_ joined #cdk
17:02 Gpox left #cdk
17:55 s9asad joined #cdk
18:31 egonw joined #cdk
18:35 egonw left #cdk
18:35 egonw joined #cdk
19:01 s9asad left #cdk
19:05 egonw left #cdk
20:10 sneumann_ left #cdk
20:10 sneumann_ joined #cdk
20:25 sneumann_ left #cdk
21:05 jbrefort left #cdk

| Channels | #cdk index | Today | | Search | Google Search | Plain-Text | summary