Earlier thread for context https://community.st.com/s/question/0D50X0000AIbA0DSQV/hsync-vsync-porch-calculations
The timing and signal forming here has history in CRT/TV display, where a raster is painted to a screen, and the electron beam paints from left to right has to return back to the left side for each new line, and to the top at the end of the frame. The concept here is that in providing the synchronization signals there needs to be time for beam to change speeds and stabilize, and separating that from the active signal.
LCD's inherited some of this, using logic gates and counters in place of the more "mechanical" nature of the magnetics/scan of old.
The LCD has expectations of speed, usually min/max/typical to function effectively. The clocking on the micro-controller side also has limitations, or where the numbers/math work better. The visible dimensions of the display are well defined, there are expectations on the sync signals, and some wiggle room in the non-display times so you can factor the numbers and get answers/solutions that fit well.
The image isn't displayed/transferred all at once. It is painted as lines. Bandwidth limits the resolution and refresh/update rate.
You also need time to update the display memory before painting it, otherwise you'll perceive tearing where you see half of one image and half of another, or that you get line noise where you are contending with the memory, the display has absolute deadlines. If you fail to meet the delivery deadlines you will get artifacts as it has to send something.
The line total (clocks for an entire line) is a sum of the front and back porches, and the active portion. The pixel clock defines the rate at which all this happens, and the units in which things are measured. Some of the clock periods will not provide any data, but will clock the synchronous logic in the display, figure counters, comparators, muxes, etc.
