You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Kevin <fo...@kegcl.demon.co.uk> on 2005/10/31 19:13:14 UTC
views v2 corner images
org.apache.forrest.plugin.output.themer corner images
I have made some progress with this. My understanding is that:
1) default corner images are in pelt.screen.css
2) these could be overridden inline by branding-theme-profiler.ft
====
1)
I will raise an enhancement jira with a new pelt.screen.css that
references corner images with hex values so the old skinconf is
not used ie:
#header .round-top-left-small {
background-image: url(../skin/images/rc-t-l-5-X294563-X4a6d8c-
X4a6d8c.png);
background-repeat: no-repeat;
background-position: top left;
}
plus
rcX.svg.xslt and corner-importsX.svg.xslt
that deal with hex values rather than skinconf names
to go in main/webapp/skins/common/images as a fallback
Note:
an update to resouces.xmap to match this request is needed:
<map:match pattern="skin/images**/*c-*-*-*-X*-X*-X*.png">
<map:call resource="read-svg2png-corner-resource">
<map:parameter name="path" value="images/{1}" />
<map:parameter name="name" value="{2}cX" />
<map:parameter name="orientation-tb" value="{3}"/>
<map:parameter name="orientation-lr" value="{4}"/>
<map:parameter name="size" value="{5}"/>
<map:parameter name="bg-color-name" value="{6}"/>
<map:parameter name="stroke-color-name" value="{7}"/>
<map:parameter name="fg-color-name" value="{8}"/>
</map:call>
not sure if this goes in the core it would be a fallback from plugin
resources.xmap if the request wasn't matched?
Also sitemap.xmap used lm for *.css matches not sure how it should be
used here. So I let it go to resources.xmap for above testing.
2)
My old work in this area fitted well with the branding-theme-profiler.ft
I have attached my version for comment. The only minor change to pelt.fv
was adding
<colors>
<!-- as before -->
</colors>
root so I could work there and let the <color> matches work as before.
====
Problem:
Item (2) xslt will work out of the box with the change to pelt.fv
but again I've tripped up as these inline corner images aren't
crawled and generated :(
Looking at the generated source the hex URLs are correctly created
and inline. This is a worrying me as 'forrest site' user.
(Well I haven't actually done any authoring yet, learning how it works
is more fun :)
If (1) works fine when pelt.screen.css is crawled. Why does (2) fail.
This is the same problem as my last attempt in views v1.
Am I missing something?
Kevin
Re: machine spec for forrest run
Posted by Thorsten Scherler <th...@apache.org>.
El jue, 03-11-2005 a las 12:25 +0000, Ross Gardler escribió:
> Thorsten Scherler wrote:
> > El jue, 03-11-2005 a las 09:59 +0000, Ross Gardler escribió:
> >
> >>Kevin wrote:
> >>
> >>>Does anyone have a performance problem using forrest run.
> >>>My test is on the main index page of seed-v2.
> >>
> >>I'm not using views 2, so cannot comment directly. However, it is known
> >>that there are lots of performance issues with views 2.
> >
> >
> > Why? If you have said v1 than you get a +1 from me because of the
> > extensive usage of xinclude which is not cacheable in v1. In v2 I do not
> > use xinclude at all (beside the default usage from main pipes of forrest
> > core).
>
> OK, maybe I spoke too soon. But I do think there is much happening in
> XSL that need not happen in a memory exhaustive approach. This is not a
> criticism of your work, merely an observation of how it can be improved
> with respect to performance.
>
Agree
> >>The tentative
> >>plan is to move much of the heavy XSL processing into Java components.
> >>Most of the stuff that is done to bring the contracts together, for
> >>example, need not be done with processor and memory intensive XSL
> >>transforms.
> >
> >
> > Actually I debugged it a bit and what I see is that the locationmap
> > lookups are taking ages. Since v2 is totally based on the lm that may
> > have introduced some new performance issues.
>
> Yeah, that too needs improving: http://issues.apache.org/jira/browse/FOR-711
>
> > Sorry for not being faster in providing a transformer for overcome the
> > xsl aggregation but I am ATM a wee bit handicapped without an internet
> > connection and moving all v2 stuff to their final locations.
>
> Come on Thorsten, you know there is no need to apologise. We don't
> expect *you* to do it, I only raise it here so that everyone is aware of
> things that need to be done and therefore how they can contribute.
>
Actually I am sorry even if I do not have to. ;-)
You are right in what you just pointed out and thanks for doing it. I
have a half baked transformer on my harddrive but then started to play
around with the theme switching stuff, run into the resource problematic
and the moving of resources.
All this work that I started on the same time is holding up the people
to go on with their work (e.g. xhtml2). ...
> >>In other words, performance has not been addressed yet.
> >
> >
> > That is not true! Like stated above I ripped out the xinclude stuff that
> > was pointed out to be the worst part for performance.
>
> Sorry, performance is being addressed, please help ;-)
>
+1
I started v2 to really address this performance issues but like Ross
stated: Please help.
> Ross
thx Ross
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: machine spec for forrest run
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> El jue, 03-11-2005 a las 09:59 +0000, Ross Gardler escribió:
>
>>Kevin wrote:
>>
>>>Does anyone have a performance problem using forrest run.
>>>My test is on the main index page of seed-v2.
>>
>>I'm not using views 2, so cannot comment directly. However, it is known
>>that there are lots of performance issues with views 2.
>
>
> Why? If you have said v1 than you get a +1 from me because of the
> extensive usage of xinclude which is not cacheable in v1. In v2 I do not
> use xinclude at all (beside the default usage from main pipes of forrest
> core).
OK, maybe I spoke too soon. But I do think there is much happening in
XSL that need not happen in a memory exhaustive approach. This is not a
criticism of your work, merely an observation of how it can be improved
with respect to performance.
>>The tentative
>>plan is to move much of the heavy XSL processing into Java components.
>>Most of the stuff that is done to bring the contracts together, for
>>example, need not be done with processor and memory intensive XSL
>>transforms.
>
>
> Actually I debugged it a bit and what I see is that the locationmap
> lookups are taking ages. Since v2 is totally based on the lm that may
> have introduced some new performance issues.
Yeah, that too needs improving: http://issues.apache.org/jira/browse/FOR-711
> Sorry for not being faster in providing a transformer for overcome the
> xsl aggregation but I am ATM a wee bit handicapped without an internet
> connection and moving all v2 stuff to their final locations.
Come on Thorsten, you know there is no need to apologise. We don't
expect *you* to do it, I only raise it here so that everyone is aware of
things that need to be done and therefore how they can contribute.
>>In other words, performance has not been addressed yet.
>
>
> That is not true! Like stated above I ripped out the xinclude stuff that
> was pointed out to be the worst part for performance.
Sorry, performance is being addressed, please help ;-)
Ross
Re: machine spec for forrest run
Posted by Thorsten Scherler <th...@apache.org>.
El jue, 03-11-2005 a las 09:59 +0000, Ross Gardler escribió:
> Kevin wrote:
> > Does anyone have a performance problem using forrest run.
> > My test is on the main index page of seed-v2.
>
> I'm not using views 2, so cannot comment directly. However, it is known
> that there are lots of performance issues with views 2.
Why? If you have said v1 than you get a +1 from me because of the
extensive usage of xinclude which is not cacheable in v1. In v2 I do not
use xinclude at all (beside the default usage from main pipes of forrest
core).
> The tentative
> plan is to move much of the heavy XSL processing into Java components.
> Most of the stuff that is done to bring the contracts together, for
> example, need not be done with processor and memory intensive XSL
> transforms.
Actually I debugged it a bit and what I see is that the locationmap
lookups are taking ages. Since v2 is totally based on the lm that may
have introduced some new performance issues.
Sorry for not being faster in providing a transformer for overcome the
xsl aggregation but I am ATM a wee bit handicapped without an internet
connection and moving all v2 stuff to their final locations.
> In other words, performance has not been addressed yet.
That is not true! Like stated above I ripped out the xinclude stuff that
was pointed out to be the worst part for performance.
> Ross
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: machine spec for forrest run
Posted by Ross Gardler <rg...@apache.org>.
Kevin wrote:
> Does anyone have a performance problem using forrest run.
> My test is on the main index page of seed-v2.
I'm not using views 2, so cannot comment directly. However, it is known
that there are lots of performance issues with views 2. The tentative
plan is to move much of the heavy XSL processing into Java components.
Most of the stuff that is done to bring the contracts together, for
example, need not be done with processor and memory intensive XSL
transforms.
In other words, performance has not been addressed yet.
Ross
machine spec for forrest run
Posted by Kevin <fo...@kegcl.demon.co.uk>.
Does anyone have a performance problem using forrest run.
My test is on the main index page of seed-v2.
It is very slow for me over 2 minutes for the first
http://localhost:8888/index.html Over 1 minute to refresh
this page.
I use a 1.2G machine with 512M memory running Linux
Fedora Core 3. CPU hits 100% about half memory used
and no swapping.
Any tips on speeding up forrest run I have tried commenting
out the debug statement in forrest.properties
Can I switch off all the debug on the console maybe that
will help?
Thanks,
Kevin
Re: views v2 corner images
Posted by Thorsten Scherler <th...@apache.org>.
Hi Kevin,
I played around with that yesterday. I run into the same problem like
you describe that the images are not generated with forrest site. :(
Actually forrest run works like a charm but the static export not.
Actually that is not the only thing that is working probably in forrest
site. The ls.contracts.xml as well is not being created.
I do not know ATM why, but we need to fix this ASAP.
salu2
El lun, 31-10-2005 a las 18:13 +0000, Kevin escribió:
> org.apache.forrest.plugin.output.themer corner images
>
> I have made some progress with this. My understanding is that:
>
> 1) default corner images are in pelt.screen.css
> 2) these could be overridden inline by branding-theme-profiler.ft
>
> ====
>
> 1)
> I will raise an enhancement jira with a new pelt.screen.css that
> references corner images with hex values so the old skinconf is
> not used ie:
> #header .round-top-left-small {
> background-image: url(../skin/images/rc-t-l-5-X294563-X4a6d8c-
> X4a6d8c.png);
> background-repeat: no-repeat;
> background-position: top left;
> }
>
> plus
>
> rcX.svg.xslt and corner-importsX.svg.xslt
> that deal with hex values rather than skinconf names
> to go in main/webapp/skins/common/images as a fallback
>
> Note:
> an update to resouces.xmap to match this request is needed:
> <map:match pattern="skin/images**/*c-*-*-*-X*-X*-X*.png">
> <map:call resource="read-svg2png-corner-resource">
> <map:parameter name="path" value="images/{1}" />
> <map:parameter name="name" value="{2}cX" />
> <map:parameter name="orientation-tb" value="{3}"/>
> <map:parameter name="orientation-lr" value="{4}"/>
> <map:parameter name="size" value="{5}"/>
> <map:parameter name="bg-color-name" value="{6}"/>
> <map:parameter name="stroke-color-name" value="{7}"/>
> <map:parameter name="fg-color-name" value="{8}"/>
> </map:call>
> not sure if this goes in the core it would be a fallback from plugin
> resources.xmap if the request wasn't matched?
>
> Also sitemap.xmap used lm for *.css matches not sure how it should be
> used here. So I let it go to resources.xmap for above testing.
>
> 2)
> My old work in this area fitted well with the branding-theme-profiler.ft
> I have attached my version for comment. The only minor change to pelt.fv
> was adding
> <colors>
> <!-- as before -->
> </colors>
> root so I could work there and let the <color> matches work as before.
>
> ====
>
> Problem:
> Item (2) xslt will work out of the box with the change to pelt.fv
> but again I've tripped up as these inline corner images aren't
> crawled and generated :(
>
> Looking at the generated source the hex URLs are correctly created
> and inline. This is a worrying me as 'forrest site' user.
> (Well I haven't actually done any authoring yet, learning how it works
> is more fun :)
>
> If (1) works fine when pelt.screen.css is crawled. Why does (2) fail.
> This is the same problem as my last attempt in views v1.
> Am I missing something?
>
> Kevin
>
>
>
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)