@nehon @pspeed
[java]
color = mix(color, texture2D(m_EffectMap, texCoord1), m_EffectStep);
[/java]
essentially m_EffectStep is g_Time… well… you get the idea… it is being updated the same.
it would be the same using g_Time
[java]
color = mix(color, texture2D(m_EffectMap, texCoord1), sin(g_Time));
[/java]
The texture is approximately 10px x 10px
Come to think of it… I would think it would be cheaper this way. Using g_Time would require another uniform for speed.
The issue only occurs on mac? or is that everywhere?
Your code looks fine to me, it shouldn’t be a killer…
Seems to be on mac
@t0neg0d said: @nehon @pspeed [java] color = mix(color, texture2D(m_EffectMap, texCoord1), m_EffectStep); [/java]essentially m_EffectStep is g_Time… well… you get the idea… it is being updated the same.
it would be the same using g_Time
[java]
color = mix(color, texture2D(m_EffectMap, texCoord1), sin(g_Time));
[/java]The texture is approximately 10px x 10px
It’s not g_Time that would kill you in the second one but sin(). I think it’s still pretty expensive.
Considering that every uniform of every material is resent every frame, I don’t think one more is going to make a big difference. But sin() will be significant unless all of my old optimization skills are totally out the window.
@pspeed, From what I understand is that the value m_EffectStep is calculated on the CPU (with sin there) and not on the GPU in this case though…
but yeah sin() should be avoided if possible but that sin() can only be part of the problem here, I have used plenty of trigonometric functions in shaders before without this big fps drop… (on the same machine).
@t0neg0d Are you doing any more texture lookups than the one posted here?
hmm strange, what do the frame stats for shaders look like? The only time i had a problem with float uniforms, is using my own when they were in the define section of the shader, and so changing them causes the shader to have to be recompiled
@kwando said: @pspeed, From what I understand is that the value m_EffectStep is calculated on the CPU (with sin there) and not on the GPU in this case though..but yeah sin() should be avoided if possible but that sin() can only be part of the problem here, I have used plenty of trigonometric functions in shaders before without this big fps drop… (on the same machine).
@t0neg0d Are you doing any more texture lookups than the one posted here?
Just the original color… hmmm @wezrule has an interesting point, though, the frame rate would dip and then go right back up. Ya know… I’m fairly sure the only define I am using is specific to eh… defining… text fields. =) But…I’ll definitely double check this.
EDIT: Only defines being used are based on static info… =( Was hoping this was the problem
@pspeed Ok… then I was on the right track avoiding sin(g_Time*speed) . It was a guess on my part… good to know for sure. And, now I know I have an old project that needs updating! =)
@kwando
Try adding this below the where the button is added:
[java]
makeWindow.removeEffect(Effect.EffectEvent.Hover);
[/java]
Just want to double check that this is the issue.
@t0neg0d, I tried with your fix but it does not help. Though It revealed the issue is onMouseOut:
I get 1700 fps when cursor is outside the button.
I get 1700 fps when hovering the button.
I get 170 fps when I leave the button with the mouse cursor.
It also happens when I click and not leaving the button.
@t0neg0d, I just downloaded the latest nightly version and now it works as it is supposed to when the pulsating effect is disabled. No issues with hovering/leaving the button. And I can make extra windows without excessive cost =)
Though if the pulsating effect is on the behavior is the same as before =/
@kwando said: @t0neg0d, I just downloaded the latest nightly version and now it works as it is supposed to when the pulsating effect is disabled. No issues with hovering/leaving the button. And I can make extra windows without excessive cost =)Though if the pulsating effect is on the behavior is the same as before =/
Ok… at least this lets me know that the issue is there. Now I just need to determine whether or not it is a) the shader or b) the control that calls effect updates. Once I narrow that down, I’ll be able to get it patched quickly. I need to write a test case for shader updates to figure out which one it is. I’ll post it soon!
@t0neg0d I know it is painful to debug and fix something when you cannot reproduce the issue locally, thanks for looking into this issue =) As before just let me know it there is anything I can do the help.
I guess it is a shader issue since most of the time disappears into rendering calls…
IMO i wouldn’t bother too much about it.
If the sin function is really the issue there not much you can do about it.
Those functions are very likely to be hardware wired on some card and not on others so, if it’s slow on some macs it’s probably due to the hardware or card drivers (@kwando, i could advice to update your drivers, but that doesn’t happen in Steve’s land 
).
I would bother if it was badly scaling with the increasing number of buttons on the page (does it by the way?). going from 1500 to 150 fps looks bad but it’s not as bad as it looks as long as you don’t go from 30 to 3 when the scene is a bit more populated.
oh…i missed that part 
Is BitmapText raising its ugly head again? ^^ Maybe you have a high fill rate due to lots of text that is not visible yet rendered?
The content of this post is meant to be read as a straight information or question without an implicit dismissive stance or interest in having the other party feel offended unless there’s emotes that hint otherwise or there’s an increased use of exclamation marks and all-capital words.
Hmm, I’m not entirely sure this is something explicitly with your library… I experience something similar in another project using the unshaded material… I will try to dig into that one and see If I can figure out what is happening.