From: nospam on
Test.


On Mon, 30 Nov 2009 14:23:01 -0600, nospam(a)noway.com wrote:

>On Thu, 26 Nov 2009 17:55:24 -0600, "Larry Serflaten"
><serflaten(a)usinternet.com> wrote:
>
>>
>>"Mike Williams" <Mike(a)WhiskyAndCoke.com> wrote
>>> > 1. Since I am using an AutoRedraw picturebox (frmChart.pctChart)
>>> > there is no need for me to do the 'double-buffer' technique because
>>> > the picturebox will already be doing this when AutoRedraw = True.
>>>
>>> Yep. That's about it.
>>
>>I would raise an objection there. The difference between drawing the chart
>>once (to an off screen buffer) and painting in place compared to drawing
>>the chart in every Resize event is going to increase as the drawing work
>>load increases. For simple (say less than 50 lines) images, the difference
>>may be neglegible, but for several hundred lines, the difference will be
>>signifcantly more noticable.
>>
>>If you're only talking about drawing the visible portion of the chart on
>>each Resize (or Scroll) event, then I would agree, there is no gain in using
>>a second buffer if VB already does it for you. But I would suggest that
>>drawing the chart once and painting to the form as needed will be more
>>responsive to user input....
>>
>>LFS
>>
>
>On average, a complete chart based on all the data loaded would be
>about 20-30 years worth. At about 200+ bars per year, that would be a
>complete chart of about 5000 vertical bars.
>
>Usually, the user will only view about 100 - 200 at a time in a single
>view. Most times, the user may scroll back another 100 - 200 bars, but
>not the whole 5000. Yet, sometimes they might.
>
>Assuming a display setting of 200 bars, the app will start out
>displaying the last 200 bars of the chart. So the DrawChart routine
>simply gets the data index for the first bar of that last 200 and
>starts drawing the chart from there.
>
>FirstBarRecNum to LastBarRecNum
>
>FirstBarRecNum contains the data array index for X = 0 on the
>picturebox. LastBarRecNum would be the 200th data array index for X =
>gHSpace * 200
>
>(gHSpace is the horizontal increment from left to right of the
>picturebox to draw the vertical bars)
>
>If the user SCROLLS this chart, the picturebox is cleared, and the
>chart is redrawn with a new FirstBarRecNum and LastBarRecNum.
>
>For example, with a single bar scroll, the FirstBarRecNum is
>incremented or decremented by 1. LastBarRecNum is then the result of
>FirstBarRecNum + 200, if there is data for it. LastBarRecNum never
>exceeds the UBound of the data array.
>
>===============
>
>So are you suggesting that the app should paint all 5000 bars on the
>non-visible picturebox and then display only a portion of it at any
>given time? What about the lines and other drawings the user may add
>to the chart and will likely save with the chart for later
>reload/display?
>
>Thanks.
>
>Webbiz
>
From: Webbiz on
test

On Mon, 30 Nov 2009 14:23:01 -0600, nospam(a)noway.com wrote:

>On Thu, 26 Nov 2009 17:55:24 -0600, "Larry Serflaten"
><serflaten(a)usinternet.com> wrote:
>
>>
>>"Mike Williams" <Mike(a)WhiskyAndCoke.com> wrote
>>> > 1. Since I am using an AutoRedraw picturebox (frmChart.pctChart)
>>> > there is no need for me to do the 'double-buffer' technique because
>>> > the picturebox will already be doing this when AutoRedraw = True.
>>>
>>> Yep. That's about it.
>>
>>I would raise an objection there. The difference between drawing the chart
>>once (to an off screen buffer) and painting in place compared to drawing
>>the chart in every Resize event is going to increase as the drawing work
>>load increases. For simple (say less than 50 lines) images, the difference
>>may be neglegible, but for several hundred lines, the difference will be
>>signifcantly more noticable.
>>
>>If you're only talking about drawing the visible portion of the chart on
>>each Resize (or Scroll) event, then I would agree, there is no gain in using
>>a second buffer if VB already does it for you. But I would suggest that
>>drawing the chart once and painting to the form as needed will be more
>>responsive to user input....
>>
>>LFS
>>
>
>On average, a complete chart based on all the data loaded would be
>about 20-30 years worth. At about 200+ bars per year, that would be a
>complete chart of about 5000 vertical bars.
>
>Usually, the user will only view about 100 - 200 at a time in a single
>view. Most times, the user may scroll back another 100 - 200 bars, but
>not the whole 5000. Yet, sometimes they might.
>
>Assuming a display setting of 200 bars, the app will start out
>displaying the last 200 bars of the chart. So the DrawChart routine
>simply gets the data index for the first bar of that last 200 and
>starts drawing the chart from there.
>
>FirstBarRecNum to LastBarRecNum
>
>FirstBarRecNum contains the data array index for X = 0 on the
>picturebox. LastBarRecNum would be the 200th data array index for X =
>gHSpace * 200
>
>(gHSpace is the horizontal increment from left to right of the
>picturebox to draw the vertical bars)
>
>If the user SCROLLS this chart, the picturebox is cleared, and the
>chart is redrawn with a new FirstBarRecNum and LastBarRecNum.
>
>For example, with a single bar scroll, the FirstBarRecNum is
>incremented or decremented by 1. LastBarRecNum is then the result of
>FirstBarRecNum + 200, if there is data for it. LastBarRecNum never
>exceeds the UBound of the data array.
>
>===============
>
>So are you suggesting that the app should paint all 5000 bars on the
>non-visible picturebox and then display only a portion of it at any
>given time? What about the lines and other drawings the user may add
>to the chart and will likely save with the chart for later
>reload/display?
>
>Thanks.
>
>Webbiz
>
From: Larry Serflaten on

<nospam(a)noway.com> wrote
> So are you suggesting that the app should paint all 5000 bars on the
> non-visible picturebox and then display only a portion of it at any
> given time? What about the lines and other drawings the user may add
> to the chart and will likely save with the chart for later
> reload/display?

No, on further understanding of the situation, the large data set precludes
trying to draw it all to memory first. One thing you might be able to make
use of is the perminent nature of the AutoRedraw image. If your chart has
a bit of border trimmings, in addition to the vertical lines, you could draw
the lines at the desired scale, and then only redraw the data.

In other words, you can draw the perminent parts of the chart with AutoRedraw
set to True, and then set AutoRedraw to False. After that, you only need to draw
the parts that change using Cls to erase the old data, leaving the perminent parts
intact. Those perminent parts could be your vertical lines and any other border
trim you have that never changes.

Just a thought to reduce the actual amount of work you need to do for each
redraw....
LFS


From: Mike Williams on
<nospam(a)noway.com> wrote in message
news:lv68h5lgpeiedah0mo7oeavi3qui8hqmuu(a)4ax.com...

> Currently, in order to show the user which bar on the chart
> the mouse is currently associated with, I have been using a
> line control (lnPriceBar) that is moved over the vertical bar
> on the chart, causing it to change color (currently to Fuchsia
> - I didn't pick it ;).
> If lRecNum <= gLastBarRecNum Then
> 'change current selected into Fuchsia
> With lnPricebar
> .BorderWidth = pctChart.DrawWidth + 2
> .x1 = gCurrentBar * gHSpace
> .y1 = dblHighPoint
> .x2 = .x1
> .y2 = dblLowPoint
> .Visible = True
> End With
> End If
> I'm assuming I'll need to do this differently if I'm going to
> use FillRect.

Not really. The code I posted the other day (the code which uses FillRect to
draw a vertical or horizontal line) uses the same variables (X1, Y1, X2, Y2)
that your original VB Line method code used, and it draws the line in
exactly the same position, pixel perfect, as would your original VB Line
method. The FillRect "line" will be in exactly the same place and will be
exactly the same length and width. The only difference is that for lines
greater than two pixels in thickness (DrawWidth > 2) the VB Line method
would produce a line that is very slightly longer than the FillRect "line"
because of the extra "rounding at the line ends" (which varies with
thickness) that the VB Line method produces at such thicknesses. So, a line
drawn using the VB Line method (using the same DrawWidth) at X1, Y1, X2, Y2
will be guaranteed to cover the line that was drawn at the same X1, Y1, X2,
Y2 coordinates using the FillRect method I posted. Does that answer your
question?

Mike




From: Webbiz on
On Mon, 30 Nov 2009 15:55:17 -0600, "Larry Serflaten"
<serflaten(a)usinternet.com> wrote:

>
><nospam(a)noway.com> wrote
>> So are you suggesting that the app should paint all 5000 bars on the
>> non-visible picturebox and then display only a portion of it at any
>> given time? What about the lines and other drawings the user may add
>> to the chart and will likely save with the chart for later
>> reload/display?
>
>No, on further understanding of the situation, the large data set precludes
>trying to draw it all to memory first. One thing you might be able to make
>use of is the perminent nature of the AutoRedraw image. If your chart has
>a bit of border trimmings, in addition to the vertical lines, you could draw
>the lines at the desired scale, and then only redraw the data.
>
>In other words, you can draw the perminent parts of the chart with AutoRedraw
>set to True, and then set AutoRedraw to False. After that, you only need to draw
>the parts that change using Cls to erase the old data, leaving the perminent parts
>intact. Those perminent parts could be your vertical lines and any other border
>trim you have that never changes.
>
>Just a thought to reduce the actual amount of work you need to do for each
>redraw....
>LFS
>


Sorry for being a dummy, but I don't follow. Border "trimmings"? Using
Cls to erase old data but leaving permanent parts intact? Cls erases
the whole picturebox, doesn't it? How would any part of it remain
intact?

A bit confused overall. o|__|

Webbiz




First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9
Prev: Snapshot of screen
Next: HTTPS File Uploads