Optimise DisplayHost.paintBuffered and DisplayHost.paintVolatileBuffered
Key: PIVOT-778
URL: https://issues.apache.org/jira/browse/PIVOT-778
Project: Pivot
Issue Type:
[
https://issues.apache.org/jira/browse/PIVOT-778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandro Martini updated PIVOT-778:
-
Fix Version/s: 2.0.1
Comments ?
Optimise DisplayHost.paintBuffered and
[
https://issues.apache.org/jira/browse/PIVOT-778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13071651#comment-13071651
]
Chris Bartlett commented on PIVOT-778:
--
Piotr - This looks interesting, but it would
[
https://issues.apache.org/jira/browse/PIVOT-776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13071658#comment-13071658
]
Chris Bartlett commented on PIVOT-776:
--
For this ticket, I will just go with whatever
[
https://issues.apache.org/jira/browse/PIVOT-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13071659#comment-13071659
]
Chris Bartlett commented on PIVOT-700:
--
I do intend to attach a simple test app, but
Hi Chris,
I wasted too much time yesterday realizing that TaskGroup
TaskSequence don't use the java.util.concurrent.ExecutorService that
might be passed to their constructors.
If I understand the issue, I think you mean that these classes are not
guaranteed to execute their subtasks using
[
https://issues.apache.org/jira/browse/PIVOT-778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13071664#comment-13071664
]
Greg Brown commented on PIVOT-778:
--
Way back, I believe we were doing something like this
[
https://issues.apache.org/jira/browse/PIVOT-656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13071665#comment-13071665
]
Chris Bartlett commented on PIVOT-656:
--
I wrote a custom DirectoryChooser component
Hi Greg. Answers in line.
On 27 July 2011 18:37, Greg Brown gk_br...@verizon.net wrote:
I wasted too much time yesterday realizing that TaskGroup
TaskSequence don't use the java.util.concurrent.ExecutorService that
might be passed to their constructors.
If I understand the issue, I think
If I understand the issue, I think you mean that these classes are not
guaranteed to execute their subtasks using the same ExecutorService that
they were given. Is that correct?
No it is a little more than that. When a standard Task is created, it
either uses a default ExecutorService or
On 27 July 2011 19:21, Greg Brown gk_br...@verizon.net wrote:
The ExecutorService given to TaskGroup and TaskSequence is used to execute
the root task (the group or sequence). It just isn't used to execute the
sub-tasks.
Fair enough, but as I said, the intent is far from clear, even with
[
https://issues.apache.org/jira/browse/PIVOT-694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13071706#comment-13071706
]
Sandro Martini commented on PIVOT-694:
--
Hi Greg, thanks for the help ... you have
If you want the sub-tasks to use the same executor service, you can just
pass that service instance to the sub-task constructor. If you pass the
fixed thread pool service to each of your individual tasks, you will get the
behavior you want.
Yes, that is what I discovered. I end up
[
https://issues.apache.org/jira/browse/PIVOT-772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noel Grandin resolved PIVOT-772.
Resolution: Fixed
Fixed in rev 1151471
Note that your code needs to change slightly:
Bounds
[
https://issues.apache.org/jira/browse/PIVOT-694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Brown resolved PIVOT-694.
--
Resolution: Fixed
I just checked in what should be a fix for this. Please re-open if the problem
[
https://issues.apache.org/jira/browse/PIVOT-694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Brown reassigned PIVOT-694:
Assignee: Greg Brown (was: Sandro Martini)
Improvement in ListButton clear() method
[
https://issues.apache.org/jira/browse/PIVOT-694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13071758#comment-13071758
]
Sandro Martini commented on PIVOT-694:
--
Hi Greg, thank you very much for the fix, I'll
On 27 July 2011 20:37, Greg Brown gk_br...@verizon.net wrote:
If you want the sub-tasks to use the same executor service, you can just
pass that service instance to the sub-task constructor. If you pass the
fixed thread pool service to each of your individual tasks, you will get
the
[
https://issues.apache.org/jira/browse/PIVOT-778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13071762#comment-13071762
]
Noel Grandin commented on PIVOT-778:
We could always use a WeakReference to allow the
[
https://issues.apache.org/jira/browse/PIVOT-694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13071761#comment-13071761
]
Greg Brown commented on PIVOT-694:
--
I'll try even on other components to verify the same
[
https://issues.apache.org/jira/browse/PIVOT-778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13071776#comment-13071776
]
Greg Brown commented on PIVOT-778:
--
Actually, since it is a volatile image, a weak
[
https://issues.apache.org/jira/browse/PIVOT-694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13071785#comment-13071785
]
Sandro Martini commented on PIVOT-694:
--
This fix only applies to ListButton.
I
[
https://issues.apache.org/jira/browse/PIVOT-778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandro Martini updated PIVOT-778:
-
Comment: was deleted
(was: Comments ?)
Optimise DisplayHost.paintBuffered and
This fix only applies to ListButton.
I understand this, I'm thinking to make similar tests on other components
that contains some data and could be selected, and see after something has
been selected, if clear reset even the selection ... for example in
ListView/TableView/TreeView/etc.
On 27 July 2011 21:51, Greg Brown gk_br...@verizon.net wrote:
Unfortunately this thread is not referenced in the javadocs :)
As this thread's existence proves, the javadocs still left me with questions.
The Javadoc says pretty much the same thing as I wrote above:
With the crucial exception
The Javadoc says pretty much the same thing as I wrote above:
With the crucial exception of how they accomplish what they
accomplish, and in particular, the use of a supplied ExecutorService.
I agree that the Javadoc could provide more detail. But the fact that TaskGroup
and TaskSequence
(I'm not ignoring your points/questions - I will get back to them in a
separate reply)
The name TaskGroup, in combination with the javadocs, made me think of
a Group of Tasks that will be executed in parallel using the (default
or optionally supplied) ExecutorService.
I suppose I saw it as a
I suppose I saw it as a ParallelTaskExecutor or TaskGroupExecutor, and
not a ParallelTask or TaskGroupTask. This is probably where the
initial confusion came from.
I can understand that. OTOH, TaskGroupTask (or ParallelTaskGroupTask) is sort
of verbose and arguably redundant, and as you
In hindsight I could have rolled this into the last email if I had
read it more thoroughly first - sorry about that!
Responses below...
On 27 July 2011 23:09, Greg Brown gk_br...@verizon.net wrote:
The Javadoc says pretty much the same thing as I wrote above:
With the crucial exception of how
On 27 July 2011 23:43, Greg Brown gk_br...@verizon.net wrote:
I suppose I saw it as a ParallelTaskExecutor or TaskGroupExecutor, and
not a ParallelTask or TaskGroupTask. This is probably where the
initial confusion came from.
I can understand that. OTOH, TaskGroupTask (or
By that logic, we'd need to qualify every class in the frame work. E.g. we
wouldn't just have a Button, we'd have a ButtonComponent. That is obviously
overkill, and I think it would be overkill here as well.
On Jul 27, 2011, at 1:11 PM, Chris Bartlett wrote:
On 27 July 2011 23:43, Greg Brown
Yes, that absolutely makes sense. The fact that it says class draws attention
away from the fact that it is actually a Task.
On Jul 27, 2011, at 1:13 PM, Chris Bartlett wrote:
On 27 July 2011 23:37, Chris Bartlett cbartlet...@gmail.com wrote:
So I might have approached it differently if ...
(I was/am not pushing to change the names - just explaining how I came
to the conclusions I did)
Right - and I'm just explaining why they are not named that way. :-)
On Jul 27, 2011, at 1:22 PM, Chris Bartlett wrote:
(I was/am not pushing to change the names - just explaining how I came
to the conclusions I did)
[
https://issues.apache.org/jira/browse/PIVOT-772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13071898#comment-13071898
]
Roger Whitcomb commented on PIVOT-772:
--
Hi Noel,
Just tried it and it seems to work
Actually, I'm not sure that logic does follow. Obviously the
Component suffix is (sanely) not used, but plenty of others are.
The 'TaskGroupTask' does actually capture something extra and the
'Task' suffix is certainly not without precedent. In fact, as far as
I can see, TaskGroup and
Actually, I'm not sure that logic does follow. Obviously the
Component suffix is (sanely) not used, but plenty of others are.
We have used suffixes where there is no common alternative. For example, we
have TabPane but not AccordionPane. Similarly, we have
org.apache.pivot.web.Query, not
Thanks for bearing with me. I assure you these are genuine
questions asked because I get the impression you have studied API
design quite a bit, or at the very least have an interest in it, and
some strong opinions. (What other kind are worth a damn?)
:-)
We have used suffixes where there
On 28 July 2011 06:06, Greg Brown gk_br...@verizon.net wrote:
We have used suffixes where there is no common alternative. For example, we
have TabPane but not AccordionPane. Similarly, we have
org.apache.pivot.web.Query, not QueryTask.
Yes, and then there are DeleteQuery, GetQuery,
I think that making TaskGroup a Group was a mistake on my part. There is no
need to ensure uniqueness here.
Actually, it just occurred to me that uniqueness, while not strictly required,
should certainly be encouraged. If you added the same task to a
ParallelTaskGroup's task sequence more
40 matches
Mail list logo
