v1.9 ßeta and lagging issue when in Raid
0 views
Skip to first unread message
Cosmic Cleric
Nov 28, 2007, 3:32:45 AM11/28/07
to develop_xub
Hey guys. I've noticed that v1.9 ßeta has lagging issues when people
enter/leave a raid. A while ago this was an issue, but I had not seen
it in v1.8, but it seems to be back again in 1.9 ßeta.
Have you guys noticed this lag at all?
enter/leave a raid. A while ago this was an issue, but I had not seen
it in v1.8, but it seems to be back again in 1.9 ßeta.
Have you guys noticed this lag at all?
Cosmic Cleric
Nov 28, 2007, 2:31:06 PM11/28/07
to develop_xub
BTW I made this post instead of creating a bug report because I wanted
to confirm with you guys that this is actually a regression bug, a new
bug, an existing bug, or I'm inhaling again. :)
to confirm with you guys that this is actually a regression bug, a new
bug, an existing bug, or I'm inhaling again. :)
Drome
Nov 28, 2007, 6:40:56 PM11/28/07
to develop_xub
I have have had some pretty low fps (3-6) on occasion - never
associated with ppl leaving or entering but will keep an eye out for
it
On Nov 28, 3:32 am, Cosmic Cleric <CosmicCle...@gmail.com> wrote:
>I've noticed that v1.9 ßeta has lagging issues when people
> enter/leave a raid. ...
associated with ppl leaving or entering but will keep an eye out for
it
On Nov 28, 3:32 am, Cosmic Cleric <CosmicCle...@gmail.com> wrote:
>I've noticed that v1.9 ßeta has lagging issues when people
Tayedaen
Dec 3, 2007, 4:59:54 AM12/3/07
to develop_xub
Hi,
the lag you were experiencing is probably coming from my change to the
perfectraid support.
And it is NOT a bug.
The problem lies here:
Perfectraid is highly configurable (that's the reason why it is such a
great addon ;-).
There are 18 checkboxes in the group definition window, and you can
make as many groups as you like by combining them at will. Each group
can have up to 40 members.
So perhaps one person has perfectraid configured to show 40 people in
one group.
An other person has one group for each class, making 9 groups.
The way XUB is checking for the existing frames is therefore:
elseif ( XUB_UF_RaidFrames == "PerfectRaid" ) then
for g=1,20 do
for u=1,40 do
In 1.8 this was g=1,20 and u =1,10, but we received an error report
then, so I had to change it.
Still my guess for groups is 20, and members NEEDS to be 40.
Now the loop running here for perfectraid takes sometime, and that's
the lag you are perceiving.
When all the work for XUB itself is done, then I will have a look at
perfectraid to determine if there is a better way to get the active
frames.
cu
tay
the lag you were experiencing is probably coming from my change to the
perfectraid support.
And it is NOT a bug.
The problem lies here:
Perfectraid is highly configurable (that's the reason why it is such a
great addon ;-).
There are 18 checkboxes in the group definition window, and you can
make as many groups as you like by combining them at will. Each group
can have up to 40 members.
So perhaps one person has perfectraid configured to show 40 people in
one group.
An other person has one group for each class, making 9 groups.
The way XUB is checking for the existing frames is therefore:
elseif ( XUB_UF_RaidFrames == "PerfectRaid" ) then
for g=1,20 do
for u=1,40 do
In 1.8 this was g=1,20 and u =1,10, but we received an error report
then, so I had to change it.
Still my guess for groups is 20, and members NEEDS to be 40.
Now the loop running here for perfectraid takes sometime, and that's
the lag you are perceiving.
When all the work for XUB itself is done, then I will have a look at
perfectraid to determine if there is a better way to get the active
frames.
cu
tay
Cosmic Cleric
Dec 3, 2007, 12:56:21 PM12/3/07
to develop_xub
I understand what you are saying (looping u from 10 up to 40). Is
there a way, perhaps by examining PerfectRaid's variables, now many
users in a raid there is, so if there is only 10, XUB doesn't try to
loop through 40 checks, and hence does less processing?
Currently, the lag is very profound. The screen literally "locks up"
for five to thirty seconds (literally), and I come back from one of
these lock-ups in pvp dead usually. Would be great to be able to
figure this one out.
there a way, perhaps by examining PerfectRaid's variables, now many
users in a raid there is, so if there is only 10, XUB doesn't try to
loop through 40 checks, and hence does less processing?
Currently, the lag is very profound. The screen literally "locks up"
for five to thirty seconds (literally), and I come back from one of
these lock-ups in pvp dead usually. Would be great to be able to
figure this one out.
Cosmic Cleric
Dec 3, 2007, 1:13:31 PM12/3/07
to develop_xub
Oh, I forgot to mention, I had opened a ticket on this issue (http://
code.google.com/p/extremeunitbuttons/issues/list).
>
> cu
> tay
code.google.com/p/extremeunitbuttons/issues/list).
> Hi,
>
> the lag you were experiencing is probably coming from my change to the
> perfectraid support.
>
> And it is NOT a bug.
>
<snip>
>
> the lag you were experiencing is probably coming from my change to the
> perfectraid support.
>
> And it is NOT a bug.
>
>
> cu
> tay
Cosmic Cleric
Dec 5, 2007, 2:19:28 PM12/5/07
to develop_xub
I was observing 1.9ß3 and the lag issue in WSG tonight. It seems that
when a new member is added, PerfectRaid adds it to the list, then it
redos its list to sort it by the sort order specificed by the
PerfectRaid configuration. This seems to make it so that XUB creates
the buttons, then when persons are moved around in the raid, deletes
and recreates the buttons when PerfectRaid is done moving things
around. If this is happening when you are away from everybody,
there's a one to three second freezing of the screen. However if this
happens when you are in the midst of things with buttons enabling/
disabling and dimming (range checks, OOM issues, etc.) the lag can
take up to fifteen or more seconds.
I tried working with the "wait to update" slider for raid issues,
thinking if I just increased the rate XUB wouldn't try doing its thing
until PerfectRaid was done moving things around, but that didn't seem
to eliminate the lag for some reason! /scratches head
Anyway, some info on the subject, for what its worth. I would suggest
that the ticket be reopened though, as it was closed (or marked as
fixed?).
when a new member is added, PerfectRaid adds it to the list, then it
redos its list to sort it by the sort order specificed by the
PerfectRaid configuration. This seems to make it so that XUB creates
the buttons, then when persons are moved around in the raid, deletes
and recreates the buttons when PerfectRaid is done moving things
around. If this is happening when you are away from everybody,
there's a one to three second freezing of the screen. However if this
happens when you are in the midst of things with buttons enabling/
disabling and dimming (range checks, OOM issues, etc.) the lag can
take up to fifteen or more seconds.
I tried working with the "wait to update" slider for raid issues,
thinking if I just increased the rate XUB wouldn't try doing its thing
until PerfectRaid was done moving things around, but that didn't seem
to eliminate the lag for some reason! /scratches head
Anyway, some info on the subject, for what its worth. I would suggest
that the ticket be reopened though, as it was closed (or marked as
fixed?).
Tayedaen
Dec 6, 2007, 6:11:49 AM12/6/07
to develop_xub
The old ticked contained info about tainting.
You sort of reported two bugs in one issue.
I decided to take the issue you created as "the tainting problem".
Since the tainting is fixed, please open a new ticket.
You sort of reported two bugs in one issue.
I decided to take the issue you created as "the tainting problem".
Since the tainting is fixed, please open a new ticket.
Drome
Dec 6, 2007, 12:08:39 PM12/6/07
to develop_xub
On Dec 6, 6:11 am, Tayedaen <vogt.mar...@gmail.com> wrote:
> You sort of reported two bugs in one issue.
Tracking multiple issues per ticket is impossible. We have the same
problem at work.
Drome
Cosmic Cleric
Dec 6, 2007, 4:20:07 PM12/6/07
to develop_xub
Will do.
Reply all
Reply to author
Forward
0 new messages