Graph too slow. Seriously?

Programming, for all ages and all languages.
Post Reply
monobogdan
Member
Member
Posts: 71
Joined: Wed Jan 25, 2017 3:37 pm

Graph too slow. Seriously?

Post by monobogdan »

Pascal Graph functions is slow. Slow like ah=9ch. But why? It must be fast because write direct in video memory
User avatar
Schol-R-LEA
Member
Member
Posts: 1925
Joined: Fri Oct 27, 2006 9:42 am
Location: Athens, GA, USA

Re: Graph too slow. Seriously?

Post by Schol-R-LEA »

monobogdan wrote:Pascal Graph functions is slow. Slow like ah=9ch. But why? It must be fast because write direct in video memory
We would really need more details about this. Which library do you mean (I am expecting you meant your own, but I don't want to assume)? What OS platform and compiler (ditto for both)? What sort of graphics (or did you mean 'graphing', which would be somewhat different)? How is it implemented?

If you can provide the source code (or better still, a link to the repo the source is in), it would also help a great deal.
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.
monobogdan
Member
Member
Posts: 71
Joined: Wed Jan 25, 2017 3:37 pm

Re: Graph too slow. Seriously?

Post by monobogdan »

Schol-R-LEA wrote:
monobogdan wrote:Pascal Graph functions is slow. Slow like ah=9ch. But why? It must be fast because write direct in video memory
We would really need more details about this. Which library do you mean (I am expecting you meant your own, but I don't want to assume)? What OS platform and compiler (ditto for both)? What sort of graphics (or did you mean 'graphing', which would be somewhat different)? How is it implemented?

If you can provide the source code (or better still, a link to the repo the source is in), it would also help a great deal.
I mean unit graph built in pascal. It's VESA wrapper.
monobogdan
Member
Member
Posts: 71
Joined: Wed Jan 25, 2017 3:37 pm

Re: Graph too slow. Seriously?

Post by monobogdan »

So, it's really too slow.

Is really VESA slow?

Code:

Code: Select all

while true do
	begin
		DrawDesktop;
		DrawStatusPanel;
		DrawTime;
		DrawRect(GetMouseX, GetMouseY, GetMouseX + 5, GetMouseY +5, 1);
	end;
monobogdan
Member
Member
Posts: 71
Joined: Wed Jan 25, 2017 3:37 pm

Re: Graph too slow. Seriously?

Post by monobogdan »

monobogdan wrote:So, it's really too slow.

Is really VESA slow?

Code:

Code: Select all

while true do
	begin
		DrawDesktop;
		DrawStatusPanel;
		DrawTime;
		DrawRect(GetMouseX, GetMouseY, GetMouseX + 5, GetMouseY +5, 1);
	end;
DrawDesktop, DrawStatusPanel, DrawTime is internal functions, it's draw rects and lines.
User avatar
nielsd
Member
Member
Posts: 31
Joined: Sun Apr 05, 2015 3:15 pm

Re: Graph too slow. Seriously?

Post by nielsd »

I don't know how DrawDesktop and DrawStatusPanel etc are implemented, but I think the real problem is in there. Don't redraw the whole desktop constantly, only draw the changed parts since previous drawing time. Also you probably don't want to keep looping and drawing, but just check if there's something to draw that has changed.
osdev project, goal is to run wasm as userspace: https://github.com/kwast-os/kwast
hannah
Member
Member
Posts: 34
Joined: Wed Oct 12, 2016 11:32 am
Location: At my PC

Re: Graph too slow. Seriously?

Post by hannah »

What does DrawRect do?
User avatar
Schol-R-LEA
Member
Member
Posts: 1925
Joined: Fri Oct 27, 2006 9:42 am
Location: Athens, GA, USA

Re: Graph too slow. Seriously?

Post by Schol-R-LEA »

I agree with ndke (and Brendan in the other thread) here; I recommend reading up on Double Buffering and blitting before you proceed. Generally speaking, you want to do something like the following:
  • Set aside two sections of the graphics memory to serve as video buffers (which I will call gbuffers).
  • Set a flag to show which of the two gbuffers is current driving the display. Clear both the display gbuffer and the shadowed gbuffer.
  • Draw the initial display to a buffer in system memory (an sbuffer).
  • Create a second (shadowed) sbuffer and copy the first sbuffer to it.
  • Create a third sbuffer for the blitter mask (mbuffer).
  • set a shadowed/display flag for the sbuffers.
  • loop:
    • if the window's contents have changed,
      • Blit the mbuffer to the shadowed gbuffer.
      • flip the shadowed gbuffer to displayed, and the other gbuffer as shadowed.
      • flip the sbuffers.
    • loop:
      • sleep the drawing process until the next vertical refresh, or a change is made to the display.
      • If a change request is made,
        • redraw the shadowed sbuffer with the new changes.
        • Use the sbuffers to generate a new mbuffer.
      • else break the inner loop
This is a general sketch, and will need to be adapted to how you intend your OS to work.
Last edited by Schol-R-LEA on Mon Jan 30, 2017 3:06 pm, edited 1 time in total.
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.
User avatar
matt11235
Member
Member
Posts: 286
Joined: Tue Aug 02, 2016 1:52 pm
Location: East Riding of Yorkshire, UK

Re: Graph too slow. Seriously?

Post by matt11235 »

monobogdan wrote:Is really VESA slow?
I think that writing to video memory is just incredibly slow.
com.sun.java.swing.plaf.nimbus.InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState
Compiler Development Forum
Post Reply