PDA

View Full Version : Astronomical clock screenlet


azathothgr
March 31st, 2007, 11:54 PM
Hello ..
This is my first try at a screenlet. I modified the ClockScreenlet code to use new graphics, and have different functionality, but they 're still very similar.

The clock is modeled after the Prague Orloj, but currently I don't know how to calculate the moon dial. It displays local time in 24h format (without minutes), local sidereal time (the little star dial) , and position of the sun at the elliptic.
Of course, these data are approximations, the screenlet is intended to be ornamental, not functional.

If anyone could help, pm me, or just modify the code and graphics and post em here.

Thanks =D
http://users.tellas.gr/~js1685/screen2.png

Download here http://users.tellas.gr/~js1685/orloj.tar.gz

Vasek
April 1st, 2007, 12:46 AM
Wooow, I have been waiting for ages to have Orloj on my desktop! Such a piece of great work!!! Excellent graphics, and transparency usage just perfectly elegant!
Thank you very much :D

Something like this being a first try... I believe there is very much to be awaited from you.[/size]

RYX
April 1st, 2007, 01:13 AM
I can only give applause :D ... Wonderful artwork. Great details.

What help do you need exactly?

@Vasek: That's another very good example for the need to implement overrideable drawing-handlers for the themes. That way the Orloj-clock could be made a functional theme of the ClockScreenlet without duplicating the code ... We should find a suitable long-term solution for doing such things :) ...

:)

Vasek
April 1st, 2007, 01:25 AM
@Vasek: That's another very good example for the need to implement overrideable drawing-handlers for the themes. That way the Orloj-clock could be made a functional theme of the ClockScreenlet without duplicating the code ... We should find a suitable long-term solution for doing such things :) ...
Which code? The only Clock-specific code which was not superseded (or commented :)) here is the save buffer approach.
And I'm not sure it is really used since I have seen redraw_foreground.

RYX
April 1st, 2007, 01:38 AM
Yes you're right, just looked into the code. Maybe a better idea for this one would be to have another abstracted base-class for all screenlets which update themselves using an offscreen buffer. Maybe something like "BufferedScreenlet". I think the whole "framework" lacks some OOP-thinking ... it's only one big class. :)

azathothgr
April 1st, 2007, 01:48 AM
Thanks , I'm glad you liked it =D

I'd appreciate some tips or some reading material on how to make svgs more lightweight, or on what are the best practices for svg graphics.. I think right now it's a little too bloated to be used with a higher update rate (for adding a seconds hand). For instance, is it better to merge multiple strokes into one shape, or just group them ?

Also, is there some way to control the pivot of rotation with cairo_context.rotate ? I tried translating before rotating a la opengl, but I couldn't seem to get it right.


Thanks again =D

Oh, also, I still can't figure out how to calculate the moon hand's angle. It's supposed to follow the local position of the moon. Out of topic, I know, but any insight would be very helpful =)

delfick
April 1st, 2007, 02:00 AM
WOW!! that's amazing :D

MacSlow
April 1st, 2007, 07:55 AM
Hey azathothgr, that's really stylish looking. Nice work!

Best regards...

MacSlow

Vasek
April 1st, 2007, 11:35 AM
I'd appreciate some tips or some reading material on how to make svgs more lightweight, or on what are the best practices for svg graphics.. I think right now it's a little too bloated to be used with a higher update rate (for adding a seconds hand). For instance, is it better to merge multiple strokes into one shape, or just group them?
Clock (screenlet) is a good example of a way to decrease CPU usage and actually I think the only one so far. You can just take all the rendering whose results do not change significantly every second (which is all the rendering right now), move it to redraw_background and set a timer to do this once in a minute. Nothing needs to be done with the SVGs then :)

Also, is there some way to control the pivot of rotation with cairo_context.rotate ? I tried translating before rotating a la opengl, but I couldn't seem to get it right. This should work normally... If you want (0, 0) to travel around (x, y) and (x, y) stay on its place, try translate(x, y) -- rotate(rot) -- translate(-x, -y). À la OpenGL.
ctx.translate(self.theme.width / 2.0, self.theme.height / 2.0);
ctx.rotate((angle)*math.pi/180);
ctx.translate(-self.theme.width / 2.0, -self.theme.height / 2.0);
at the beginning of on_draw produces: http://kfe.fjfi.cvut.cz/~potocek/work/storage/rotate.jpg

Oh, also, I still can't figure out how to calculate the moon hand's angle. It's supposed to follow the local position of the moon. Out of topic, I know, but any insight would be very helpful =)
Aha, I thought this was the main question. I'm afraid unless you tell where you have the other calculations from, nobody will be able to do the same for the Moon... All the constants in lds themselves look frightening enough.

azathothgr
April 1st, 2007, 12:44 PM
Clock (screenlet) is a good example of a way to decrease CPU usage and actually I think the only one so far. You can just take all the rendering whose results do not change significantly every second (which is all the rendering right now), move it to redraw_background and set a timer to do this once in a minute. Nothing needs to be done with the SVGs then :)


I'll try that. I'd like to add some ornate minute and second hand, perhaps placed in an unconventional way, and experiment with smoother movement for the seconds hand. Different update rates could make that possible, and perhaps adding more buffered layers.

The same would apply to a (still fictional ) tall-case clock screenlet , complete with swinging pendulum :P


This should work normally... If you want (0, 0) to travel around (x, y) and (x, y) stay on its place, try translate(x, y) -- rotate(rot) -- translate(-x, -y). À la OpenGL.
ctx.translate(self.theme.width / 2.0, self.theme.height / 2.0);
ctx.rotate((angle)*math.pi/180);
ctx.translate(-self.theme.width / 2.0, -self.theme.height / 2.0);
at the beginning of on_draw produces: http://kfe.fjfi.cvut.cz/~potocek/work/storage/rotate.jpg


Weird, I'm sure I tried the exact same thing with one of the hands. I guess I did something wrong ..


Aha, I thought this was the main question. I'm afraid unless you tell where you have the other calculations from, nobody will be able to do the same for the Moon... All the constants in lds themselves look frightening enough.

The formulas are from http://www.jgiesen.de/elevaz/basics/meeus.htm#sidereal
and from Wikipedia's article on 'Julian Day' .

Argh there are some typos and stupid mistakes : latitude should be longitude, evidently .. and lds() should be lst() local sidereal time .. I have NO idea where lds came from heh ....

[/url]

Vasek
April 1st, 2007, 01:04 PM
The same would apply to a (still fictional ) tall-case clock screenlet , complete with swinging pendulum :P
And the Apostles every hour? :D
The pendulum is hidden somewhere inside the building... You'd have to think it up as well as the additional hands, in which case I would ask for making it both optional.

Edit: Can you convert the numerals 1-12 to curves too, please?

Sorcerer
April 1st, 2007, 06:55 PM
Nice job, azathothgr! I really like it:D I'll include it in the next debian package (if you are OK with it). Could you please upload it here (http://hendrik.kaju.pri.ee/screenlets) also?

Vasek
April 1st, 2007, 07:09 PM
I found a few issues with setting scale to something other that 1, in the concrete with Sun and its spindle. If you won't mind, I wrote a small patch (http://kfe.fjfi.cvut.cz/~potocek/work/storage/orloj-scale.patch) which should make it more transparent and preclude further such errors.

azathothgr
April 3rd, 2007, 01:25 AM
Thanks for the patch Vasek, I missed that one..

DL here :
http://users.tellas.gr/~js1685/orloj0.2.tar.gz

It works ok now.
I added the moon hand / moon phase, and made some changes to the way things are drawn, to match the buffered approach. Now while the applet refreshes each second (for no real reason yet, no seconds hand), everything is redrawn each minute, to a buffer, and just painted each second. I think it uses somewhat less cpu , but definitely more than what would allow for smaller update cycles.

Also, I changed the way shadows were rendered : the foreground layer is used as a mask now , to paint on a new 'shadow' buffer layer which then is painted with some transcluency, in a position relative to that of the applet's window on the desktop. The result is as if there's a light source in the top left corner of the desktop (with some imagination :P ). And there's no need for separate 'X-shadow' svgs =D

One drawback is that when you change settings such as time offset, the changes won't be visible until the foreground layer redraws, or until one re-selects the default theme to force a redraw.

Is there any way to further reduce cpu load ?

Vasek
April 3rd, 2007, 11:13 PM
Thanks for the new version! It's still more beautiful. I must try out its precision someday :)

Is there any way to further reduce cpu load? I'm afraid you can't do much more for it than you do now... I think the CPU load is high solely due to the window size right now, that it's not your application but the compositing manager what causes it. Maybe you can try to redraw only some "damaged" regions of the window every second? RYX should know, I have never done that.

RYX
April 4th, 2007, 09:35 AM
Thanks for the new version! It's still more beautiful. I must try out its precision someday :)

Is there any way to further reduce cpu load? I'm afraid you can't do much more for it than you do now... I think the CPU load is high solely due to the window size right now, that it's not your application but the compositing manager what causes it. Maybe you can try to redraw only some "damaged" regions of the window every second? RYX should know, I have never done that.
The next version will have an improved redraw_canvas()-function which optionally allows redrawing only a portion of the whole screenlet. I am unsure how much CPU-load you can reduce in your case but for the normal Clock it would make about 2/3 of all drawings obsolete (for the Sticknotes even more).